Oracle Internet Directory Administrator's Guide
Release 2.1.1
Part Number A86101-01

Library
Solution Area
Contents
Index

Go to previous page Go to next page

2
Concepts and Architecture

This chapter provides conceptual descriptions of the basic elements of Oracle Internet Directory and discusses Oracle Internet Directory architecture.

This chapter contains these topics:

Entries

In a directory, each collection of information about an object is called an entry. For example, a typical telephone directory includes entries for people, and a library card catalog contains entries for books. Similarly, an online directory might include entries for employees, conference rooms, e-commerce partners, or shared network resources such as printers.

Each entry in a directory is uniquely identified by a distinguished name (DN). The distinguished name tells you exactly where the entry resides in the directory's hierarchy. This hierarchy is represented by a directory information tree (DIT).

To understand the relation between a distinguished name and a directory information tree, look at the example in Figure 2-1.

Figure 2-1 A Directory Information Tree


Text Description of oid81025.gif follows
Text description of the illustration oid81025.gif

The DIT in Figure 2-1 diagrammatically represents entries for two employees of Acme Corporation who are both named Anne Smith. It is structured along geographical and organizational lines. The Anne Smith represented by the left branch works in the Sales division in the United States, while the other works in the Server Development division in the United Kingdom.

The Anne Smith represented by the right branch has the common name (cn) Anne Smith. She works in an organizational unit (ou) named Server Development, in the country (c) of Great Britain (uk), in the organization (o) Acme.

The DN for this "Anne Smith" entry is: 

cn=Anne Smith,ou=Server Development,c=uk,o=acme

Note that the conventional format of a distinguished name places the lowest DIT component at the left, then follows it with the next highest component, thus moving progressively up to the root.

Within a distinguished name, the lowest component is called the relative distinguished name (RDN). For example, in the above entry for Anne Smith, the RDN is cn=Anne Smith. Similarly, the RDN for the entry immediately above Anne Smith's RDN is ou=Server Development, the RDN for the entry immediately above ou=Server Development is c=uk, and so on. A DN is thus a sequence of RDNs separated by commas.

To locate a particular entry within the overall DIT, a client uniquely identifies that entry by using the full DN--not simply the RDN--of that entry. For example, within the global organization in Figure 2-1, to avoid confusion between the two Anne Smiths, you would use each one's full DN. (If there are potentially two employees with the same name in the same organizational unit, you could use additional mechanisms, such as identifying each employee with a unique identification number.)

See Also:

Chapter 7, "Managing Directory Entries." 

Attributes

In a typical telephone directory, an entry for a person contains such information items as an address and a phone number. In an online directory, these information items are called attributes. Attributes in a typical employee entry can include, for example, a job title, an e-mail address, or a phone number.

For example, in Figure 2-2, the entry for Anne Smith in Great Britain (uk) has several attributes, each providing specific information about her. These are listed in the balloon to the right of the tree, and they include emailaddrs, printername, jpegPhoto, and app preferences. Moreover, each bullet in Figure 2-2 is also an entry with attributes, although the attributes for each are not shown.

Figure 2-2 Attributes of the Entry for Anne Smith


Text Description of oid81011.gif follows
Text description of the illustration oid81011.gif

Each attribute consists of an attribute type and one or more attribute values. The attribute type identifies the kind of information that the attribute contains--for example, jobTitle. The attribute value is the particular occurrence of information appearing in that entry. For example, the value for the jobTitle attribute could be manager.

This section contains these topics:

Kinds of Attribute Information

Attributes contain two kinds of information.

Application Information 

This information is maintained and retrieved by the directory clients and is unimportant to the operation of the directory. A telephone number, for example, is application information. 

Operational Information 

This information pertains to the operation of the directory itself. Some operational information is specified by the directory to control the server--for example, the time stamp for the creation or modification of an entry, or the name of the user who creates or modifies an entry. Other operational information, such as access information, is defined by administrators and is used by the directory program in its processing. 

Any given attribute can hold either application information, or operational information, but not both.

To enhance your ability to search for entries, Oracle Internet Directory automatically creates several system operational attributes when you add an entry to the directory. These include:

creatorsName 

Name of the person creating the entry 

createTimestamp 

Time of entry creation in UTC (Coordinated Universal Time) 

modifiersName 

Name of person creating the entry 

modifyTimestamp 

Time of entry creation in UTC 

Moreover, when a user modifies an entry, Oracle Internet Directory automatically updates the modifiersName and modifyTimestamp attributes as follows:

modifiersName 

Name of person modifying the entry 

modifyTimestamp 

Time of entry modification in UTC 

See Also:

"Setting System Operational Attributes" for instructions on configuring system operational attributes 

Single-Valued and Multi-Valued Attributes

Attributes can be either single-valued or multi-valued. Single-valued attributes carry only one value in the attribute, whereas multi-valued attributes can have several. An example of a multi-valued attribute is a group membership list with names of everyone in the group.

Common LDAP Attributes

Oracle Internet Directory implements all of the standard LDAP attributes. Table 2-1 shows some of the more common LDAP attributes.

Table 2-1 Common LDAP Attributes
Attribute Type  Attribute String  Description  Example of Attribute Value 

commonName 

cn 

Common name of an entry 

cn=Anne Smith 

domainComponent 

dc 

Component in a Domain Name System (DNS) 

The following DN:
dc=uk,dc=acme,dc=com 

jpegPhoto 

jpegPhoto 

Photographic image in JPEG format. The path and file name of the JPEG image you want to include as an entry attribute. 

/photo/audrey.jpg 

organization 

o 

Name of an organization 

o=acme 

organizationalUnitName 

ou 

Name of a unit within an organization 

ou=Server Development 

owner 

owner 

Distinguished name of the person who owns the entry 

The following line in an LDIF file:

owner: cn=Anne Smith, ou=Server Development, o= Acme, c=uk 

surname, sn 

sn 

Last name of a person 

Smith 

telephoneNumber 

telephoneNumber 

Telephone number 

telephoneNumber=(650) 123-4567

or

telephoneNumber=6501234567 

See Also:

Appendix E for a list of several proprietary attributes Oracle Internet Directory provides. 

Attribute Syntax

Attribute syntax is the format of the data that can be loaded into each attribute. For example, the syntax of the telephoneNumber attribute might require a telephone number to be a string of numbers containing spaces and hyphens. However, the syntax for another attribute might require specifying whether the data has to be in the form of a date, or whether the data can consist of numbers only. Each attribute must have one and only one syntax attached to it.

Oracle Internet Directory recognizes most of the syntax specified in RFC 2252, allowing you to associate most of the syntax described in that document with an attribute. In addition, Oracle Internet Directory also enforces some LDAP syntax. You cannot add new syntaxes beyond those already supported by Oracle Internet Directory.

See Also:

"LDAP Syntax" 

Attribute Matching Rules

In response to most incoming client requests, the directory server performs search and compare operations. During these operations, the directory server consults relevant matching rule to determine equality between the attribute value sought and the attribute value stored. For example, matching rules associated with the telephoneNumber attribute could cause "(650) 123-4567" to be matched with either "(650) 123-4567" or "6501234567" or both. When you create an attribute, you associate a matching rule with it.

Oracle Internet Directory implements all the standard LDAP matching rules. You cannot add new matching rules beyond those already supported by Oracle Internet Directory.

See Also:

"Matching Rules" 

Attribute Options

An attribute type can have various options that enable you to specify how the value for that attribute is made available in a search or a compare operation. For example, suppose that an employee has two addresses, one in London, the other in New York. Options for that employee's address attribute could allow you to store both addresses. Moreover, attribute options can include language codes. For example, options for John Doe's givenName attribute could enable you to store his given name in both French and Japanese.

An attribute with one or more options has the properties--for example, matching rules and syntax-- of its base attribute, which has no options. For example, suppose that cn is the base attribute. If cn;lang-fr=Jean is the French value for that base attribute, then it has the same matching rules and syntax as cn.

Note:

You cannot use an attribute option within a DN. For example, the following DN is incorrect: cn;lang-fr=Jean, ou=sales,o=acme,c=uk. 

See Also:

Chapter 6, "Managing the Directory Schema."  

Object Classes

An object class is a group of attributes. When you define a directory entry, you assign one or more object classes to it. These object classes contain attributes, some of which are mandatory and some of which are optional.

For example, the organizationalPerson object class includes the mandatory attributes commonName (cn) and surname (sn). When you define an entry by using the organizationalPerson object class, you must specify values for these attributes. This object class also includes several optional attributes, including telephoneNumber, uid, streetAddress, and userPassword. You do not need to provide values for these latter attributes when using the organizationalPerson object class.

At installation, Oracle Internet Directory provides standard LDAP object classes, as well as several proprietary object classes. You cannot add mandatory attributes to the sets of attributes belonging to these predefined object classes. If a given object class does not contain all the attributes that you want for an entry, then you can do one of the following:

This section contains these topics:

Subclasses, Superclasses, and Inheritance

A subclass is an object class derived from another object class. The object class from which it is derived is called its superclass. For example, the object class organizationalPerson is a subclass of the object class person. Conversely, the object class person is the superclass of the object class organizationalPerson.

A subclass inherits all of the attributes belonging to its superclass. Entries may inherit the attributes defined by multiple object classes.

Note:

In itself, an object class contains no values. Only an instance of an object class contains values. When a subclass inherits attributes from a superclass, it inherits only the attribute framework--not the attribute values--of the superclass 

One special object class, called top, has no superclasses. It is one of the superclasses of every structural object class in the directory, and its attributes are inherited by every entry.

Object Class Types

There are three types of object classes:

Abstract Object Classes

An abstract object class is a virtual object class, which means that it cannot be the only object class for an entry. For example, the object class top is an abstract object class. It is required as a superclass for all structural object classes, but it cannot be used alone.

The top object class includes the mandatory attribute objectClass as well as several optional attributes. The following list contains the names of the optional attributes in top and either describes or points to further information about each one.

Structural Object Classes

Structural object classes describe the basic aspects of an object. Most of the object classes that you use are structural object classes, and every entry should belong to at least one structural object class. Examples of structural object classes are person and groupOfNames.

These object classes place restrictions on which kinds of object classes can be created under any given object class. For example, a structure rule might require all objects below the organization (o) object class to be organizational units (ou). Following this rule, you could not enter person objects directly below an organization object class.

Auxiliary Object Classes

Auxiliary object classes are groupings of attributes that expand the existing list of attributes in an entry. For example, suppose you have defined an entry as a member of two object classes, and you want to assign to that entry additional attributes that do not belong to either of the two object classes. You can create a new auxiliary object class containing the extra attributes, and then associate that auxiliary object class with the entry. This is an alternative to redefining existing object classes.

Unlike structural object classes, auxiliary classes do not place restrictions on where an entry may be stored.

Note:

Oracle Internet Directory does not enforce structure rules. It therefore handles both structural and auxiliary object classes in the same way. 

See Also:

Chapter 6, "Managing the Directory Schema."  

Naming Contexts

A naming context is a subtree that resides entirely on one server. It must be contiguous, that is, it must begin at an entry that serves as the top of the subtree, and extend downward to either leaf entries or references to subordinate naming contexts. It can range in size from a single entry to the entire DIT.

Figure 2-3 illustrates valid and invalid naming contexts. Notice that the correct ones on the left are contiguous, and the incorrect ones on the right are not.

Figure 2-3 Valid and Invalid Naming Contexts


Text Description of oid81019.gif follows
Text description of the illustration oid81019.gif

To enable users to search for specific naming contexts, you can publish those naming contexts by using either Oracle Directory Manager or ldapmodify.

See Also:

"Managing Naming Contexts" for instructions on how to publish a naming context 

The Directory Schema

The directory schema contains all information about how data is organized in the DIT--that is, metadata such as object classes, attributes, matching rules, and syntaxes. The directory schema stores this information in a special class of entry called a subentry. Oracle Internet Directory, following LDAP Version 3 standards, holds schema definitions in the subentry called subSchemaSubentry.

You can add new object classes and objects by modifying subSchemaSubentry. You cannot, however, add new matching rules and syntaxes beyond those already supported by Oracle Internet Directory.

See Also:

 

Security

Oracle Internet Directory provides many powerful mechanisms for protecting information from unauthorized access.

This section contains these topics:

Authentication

Authentication is the process by which the directory server establishes the true identity of the user connecting to the directory. It occurs when an LDAP session is established by means of the ldap-bind operation. Thus every session has an associated user identity. This identity is also referred to as an authorization ID.

To ensure that the identities of users, hosts, and clients are correctly known, Oracle Internet Directory provides three authentication options: anonymous, simple, and SSL.

Anonymous Authentication

If your directory is available to everyone, then you can allow users to log in to the directory anonymously. When using anonymous authentication, users simply leave blank the user name and password fields when they log in. Each anonymous user then exercises whatever privileges are specified for anonymous users.

Simple Authentication

In this case, the client identifies itself to the server by means of a DN and a password which are not encrypted when sent over the network. In the simple authentication option, the server verifies that the DN and password sent by the client match the DN and password stored in the directory.

Authentication Using Secure Sockets Layer (SSL)

SSL is an industry standard protocol for securing network connections. It provides authentication through the exchange of certificates that are verified by trusted certificate authorities. A certificate ensures that an entity's identity information is correct. An entity can be an end user, a database, an administrator, a client, or a server. A certificate authority (CA) is an application that creates public key certificates that are given a high level of trust by all the parties involved.

You can use SSL in one of three authentication modes:

SSL Mode  Description 

No authentication 

Neither the client nor the server authenticates itself to the other. No certificates are sent or exchanged. In this case, only SSL encryption/decryption is used. 

One-way authentication 

Only the directory server authenticates itself to the client. The directory server sends the client a certificate verifying that the server is authentic. 

Two-way authentication 

Both client and server authenticate themselves to each other. Both the client and server send certificates to each other. 

Components of SSL

The components of SSL include:

The SSL Handshake

At the beginning of their communication, the client and directory server perform a handshake which includes three important steps:

SSL and Oracle Internet Directory

SSL authentication between a client and a directory server involves three basic steps:

  1. The user initiates an LDAP connection to the directory server by using SSL on the SSL port. (The default SSL port is 636.)

  2. SSL performs the handshake between client and directory server.

  3. If the handshake is successful, the directory server verifies that the user has the appropriate authorization to access the directory.

    See Also:

     

Access Control and Authorization

Authorization is the process of ensuring that a user reads or updates only the information for which that user has privileges. When directory operations are attempted within a directory session, the directory server ensures that the user-- identified by the authorization ID associated with the session--has the requisite permissions to perform those operations. Otherwise, the operation is disallowed. Through this mechanism, the directory server protects directory data from unauthorized operations by directory users. This mechanism is called access control.

Access control information is the directory metadata that captures the administrative policies relating to access control.

ACI is stored in Oracle Internet Directory as user-modifiable operational attributes. Typically, a list of these ACI attribute values, called an Access Control List (ACL), is associated with directory objects. The attribute values on that list govern the access policies for those directory objects.

ACIs are represented and stored as text strings in the directory. These strings must conform to a well defined format. Each valid value of an ACI attribute represents a distinct access control policy. These individual policy components are referred to as ACI Directives or ACIs and their format is called the ACI Directive format.

Access control policies can be prescriptive, that is, their security directives can be set to apply downward to all entries at lower positions in the directory information tree (DIT). The points from which such access control policies apply are called Access Control Policy Points (ACPs).

See Also:

 

Data Integrity

Oracle Internet Directory ensures that data has not been modified, deleted, or replayed during transmission by using SSL. This SSL feature generates a cryptographically secure message digest--through cryptographic checksums using either the MD5 algorithm or the Secure Hash Algorithm (SHA)--and includes it with each packet sent across the network.

Data Privacy

Oracle Internet Directory ensures that data is not disclosed during transmission by using public-key encryption available with Secure Sockets Layer (SSL). In public-key encryption, the sender of a message encrypts the message with the public key of the recipient. Upon delivery, the recipient decrypts the message using the recipient's private key. Specifically, Oracle Internet Directory supports two levels of encryption available through SSL:

Password Encryption

During installation, you were prompted to set the encryption scheme for passwords. You can change that initial configuration by using either Oracle Directory Manager or ldapmodify. You must be a superuser to change the type of password encryption.

To encrypt passwords, Oracle Internet Directory uses the MD4 algorithm as the default. MD4 is a one-way hash function that produces a 128-bit hash, or message digest. You can change this default to one of the following:

The value you specify is stored in the orclCryptoScheme attribute in the Root DSE. This attribute is single-valued.

During authentication to a directory server, a user enters a password in clear text. The server then hashes the password by using the specified encryption algorithm, and verifies it against the hashed password in the userPassword attribute. If the hashed password values match, then the server authenticates the user. If the hashed password values do not match, then the server sends the user an Invalid Credentials error message.

See Also:

"Managing Password Encryption" 

National Language Support

Oracle Internet Directory follows LDAP Version 3 internationalization (I18N) standards. These standards require that the database storing directory data use the UTF-8 (Unicode Transformation Format 8-bit) character set. This allows Oracle Internet Directory to store the character data of almost any language that Oracle NLS supports. Moreover, although several different Application Program Interfaces (APIs) are involved in the Oracle Internet Directory implementation, Oracle Internet Directory ensures that the correct character encoding is used with each API.

NLS uses both single-byte and multi-byte characters. A single-byte character is represented by one byte of memory. ASCII text, for example, uses single-byte characters. By contrast, a multi-byte character can be represented by more than one byte. Simplified Chinese, for example, uses multi-byte characters. A directory entry in simplified Chinese might look like this: 

dn: o=\274\327\271\307\316\304,c=\303\300\271\372
objectclass: top
objectclass: organization
o: \274\327\271\307\316\304

where the attribute values correspond to character strings in the simplified Chinese character set.

The main Oracle Internet Directory components--OID Monitor (OIDMON), OID Control Utility (OIDCTL), Oracle directory server (OIDLDAPD), and Oracle directory replication server (OIDREPLD)--always use the UTF-8 character set by default.

Oracle Directory Manager, a Java-based tool, internally uses Unicode (UCS2--that is, fixed-width 16-bit Unicode). In Java, UCS2 is the easiest way to handle characters--including English characters. The Java client uses standard Java packages to convert both to and from UCS2 and UTF-8. This enables Oracle Directory Manager to handle the LDAP Version 3 protocol using UTF-8.

See Also:

 

Oracle Internet Directory Architecture

This section contains these topics:

An Oracle Internet Directory Node

Figure 2-4 shows the various directory server components and their relationships running on a single node.

Net8 is used for all connections between the Oracle database server and:

LDAP is used for connections between The LDAP Server Instance 1 non-SSL port 389 and:

The two LDAP server instances and the replication server connect to OID Monitor by way of the operating system.

Figure 2-4 A Typical Oracle Internet Directory Node


Text Description of oid81005.gif follows
Text description of the illustration oid81005.gif

Note:

In Figure 2-4, the database is on the same node as the directory server processes. However, because all connections with the database are through Oracle Call Interface (OCI) and Net8, it is possible to use a database on a different server. 

An Oracle Internet Directory node (Figure 2-4) includes the following major components:

Component  Description 

LDAP server instance 

Also called an Oracle directory server instance. It services directory requests through a single Oracle Internet Directory dispatcher process listening at a specific TCP/IP port number. There can be more than one LDAP server instance on a node, each listening on a different port. Oracle Internet Directory dispatcher and server processes use multiple threads. 

Replication server 

Also called an Oracle directory replication server. It tracks and sends changes to replicated servers in an Oracle Internet Directory system. There can be only one replication server on a node. You can choose whether or not to install and use the replication server. 

Oracle8i database 

Stores the directory data. Oracle Corporation strongly recommends that you dedicate a database for use by the directory. The database can reside on the same node as the servers, or on a separate node. 

OID Monitor (OIDMON) 

Initiates, monitors, and terminates the LDAP server processes. If you elect to install a replication server, OID Monitor controls it. When you issue commands through OID Control Utility (OIDCTL) to start or stop directory server instances, your commands are interpreted by this process.

OID Monitor executes the LDAP server instance startup and shutdown requests that you initiate from OID Control Utility. OID Monitor also monitors servers and restarts them if they have stopped running for abnormal reasons.

When it starts a server instance, OID Monitor adds an entry into the directory instance registry and updates data in a process table. When it shuts down the directory server instance, it deletes the registry entry as well as the data corresponding to that particular instance from the process table. If OID Monitor restarts a server that has stopped abnormally, it updates the registry entry with the start time of the server.

All OID Monitor activity is logged in the file
ORACLE_HOME/ldap/log/oidmon.log. This file is on the Oracle Internet Directory server file system.

OID Monitor checks the state of the servers through mechanisms provided by the operating system. 

OID Control Utility (OIDCTL) 

Communicates with OID Monitor by placing message data in Oracle Internet Directory server tables. This message data includes configuration parameters required to run each Oracle directory server instance. 

The Oracle directory replication server uses LDAP to communicate with an Oracle directory (LDAP) server instance. To communicate with the database, all components use OCI/Net8. Oracle Directory Manager and the command line tools communicate with the Oracle directory (LDAP) servers over LDAP.

An Oracle Directory (LDAP) Server Instance

Each Oracle directory (LDAP) server instance looks similar to what Figure 2-5 illustrates.

Figure 2-5 LDAP Server Instance Architecture


Text Description of oid81006.gif follows
Text description of the illustration oid81006.gif

LDAP clients send LDAP requests to an Oracle Internet Directory listener/dispatcher process listening for LDAP commands at its port.

The OID listener/dispatcher launches the LDAP directory server which, in turn creates server processes. Multiple server processes allow Oracle Internet Directory to take advantage of multiple processor systems. The number of server processes created is determined by a configuration parameter (ORCLSERVERPROCS). The default is 1 (one). A worker thread for each operation processes the client request.

Database connections from each server process are spawned as needed, up to a maximum number determined by a configuration parameter (ORCLMAXCC). The default value for this parameter is 10. The server processes communicate with the data server by way of Net8. A Net8 Listener/Dispatcher relays the request to the Oracle data server.

Configuration Set Entries

The configuration parameters for each Oracle directory server instance are stored in a directory entry called a configuration set entry, or configset. A configuration set entry holds the configuration parameters for a specific instance of the directory server. When you start an instance of a server using OID Control Utility, the command contains a reference to one of these configsets and uses the information it contains.

The Oracle directory server is installed with a default configuration set entry (configset0) so that you can run the directory server immediately. You can create customized configuration set entries by adding new ones that change specific parameters to meet your needs. You can view, add, and modify these entries by using either Oracle Directory Manager or the appropriate command line tool.

See Also:

 

Example: How Oracle Internet Directory Works

Now that all of the concepts are introduced, the following example shows you how Oracle Internet Directory processes a search request.

  1. The user or client enters a search request that is conditioned by one or more of the following options:

    • SSL: The client and server can establish a session that uses SSL encryption and authentication, or SSL encryption only. If SSL is not used, the client's message is sent in clear text.

    • Type of user: The user can seek access to the directory either as a particular user or as an anonymous user, depending on which of the two has the necessary privileges to perform the desired function.

    • Filters: The user can narrow the search by using one or more search filters, including those that use the Boolean conditions "and," "or," and "not," and those that use other operators such as "greater than, "equal to," and "less than".

  2. If the user or client issues the command by using Oracle Directory Manager, the latter invokes a query function in the Java Native Interface which, in turn, invokes a function in the C API. If the user or client uses a command line tool, then the tool directly invokes a C function in the C API.

  3. The C API, using the LDAP protocol, sends a request to a directory server instance to connect to the directory.

  4. The directory server authenticates the user, a process called binding. The directory server also checks the Access Control Lists (ACLs) to verify that the user is authorized to perform the requested search.

  5. The directory server converts the search request from LDAP to Oracle Call Interface (OCI)/Net8 and sends it to the Oracle8i database.

  6. The Oracle8i database retrieves the information and passes it back through the chain--to the directory server, then to the C API, and, finally, to the client.

Distributed Directories: An Overview

Although an online directory is logically centralized, it can physically distribute its data onto several servers. Physical distribution reduces the work a single server would otherwise have to do. It also enables the directory to accommodate a larger number of entries.

A distributed directory can be either replicated or partitioned. When information is replicated, the same naming contexts are stored by more than one server. When information is partitioned, each directory server stores one or more unique, non-overlapping naming contexts. In a distributed directory, some information may be partitioned and some may be replicated.

See Also:

 

Distributed Directories: Replication

Replication is one way of distributing directory information. It improves performance by providing more servers to handle queries. It improves reliability by eliminating risks associated with a single point of failure.

Each copy of a naming context that is contained within a server is called a replica. A directory server can hold both read-only and updatable replicas.

Servers that hold updatable replicas are called suppliers. Their changes are propagated to other servers called consumers.

You specify how many times the replication server should try to apply changes to consumers. Once that number is reached, the replication server moves the changes to a human intervention queue, then attempts to apply them at regular, less frequent intervals that you specify.

Figure 2-6 shows a replicated directory.

Figure 2-6 A Replicated Directory


Text Description of oid81009.gif follows
Text description of the illustration oid81009.gif

Note:

This release of Oracle Internet Directory enables replication at the level of the naming context. It does not support replication of part of a naming context.

Also, although there are no Internet standards for directory replication yet, such standards are being developed by the IETF. Oracle Internet Directory replication adheres to the IETF standard proposal for representing directory change information in change logs. 

See Also:

"Replication Architecture" for more on change logs 

This section contains these topics:

Directory Replication Groups and Replication Agreements

The set of directory servers that participate in replication of a given naming context is called a Directory Replication Group (DRG). A special directory entry, called a replication agreement, represents the replication relationship among the directory servers in a DRG.

It is possible for a directory server to be both a supplier and a consumer of change log information. Oracle Internet Directory uses this feature to support multimaster replication.

Figure 2-7 illustrates a Directory Replication Group in which three nodes share updates with each other in a replication agreement.

Figure 2-7 Directory Replication Group


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

In Figure 2-7, each bullet represents a node of Oracle Internet Directory. The agreement is identical on each node except for local options such as partitioned naming contexts on the local directory server. The replication agreement on each node lists all the other nodes to which it delivers, and from which it receives, changes.

See Also:

"Task 5: Configure Replication" for information about how to configure replication agreements 

Oracle Advanced Symmetric Replication (ASR)

Transport of update information between nodes in a replication agreement is managed by Oracle Advanced Symmetric Replication (ASR), a store-and-forward transport feature available in Oracle8i. It allows database tables to be kept synchronized across two Oracle databases.

ASR stores local changes and periodically propagates them in batches to consumer servers. The consumer replication servers apply the remote changes to the local directory server and then purge the applied remote changes from their local stores.

ASR environments allow read and update access to directory tables anywhere in the system. Typical ASR configurations use row-level replication with asynchronous data propagation.

ASR provides proven network tolerance and its data transfer can be controlled and monitored by Oracle Enterprise Manager. Such manageability allows a high degree of flexibility in how the data transfer is scheduled.

See Also:

Oracle8i Replication for information about ASR 

Replication Architecture

Supplier servers write their changes to change logs, and then regularly send batched directory changes to other supplier and consumer servers. Consumer servers receive the change log data, then reproduce the changes locally.

When you configure replication, you specify which nodes in a replication group share changes. Regardless of the number of nodes you introduce into the replication environment, the basic architecture for replication remains the same. Local changes are distributed to remote nodes and applied by replication server processing. To apply the changes on a remote node, the replication server, acting as a client, sends commands to the directory server that implements them.

See Also:

"Task 5: Configure Replication" for information on configuring replication 

Change Log Purging

Change log purging takes place in Oracle Internet Directory in two ways:

Change number-based 

This is the default method. The replication server purges those changes that have already been applied to all the nodes in a DRG. 

Time-based 

You can run this method to augment change number-based purging. To use this additional method, you set a parameter specifying in hours the lifespan of change log objects. For example, you can set this parameter to purge all change log objects that are 24 hours old. Use this method to prevent the change log from becoming too large. 

See Also:

 

Conflict Resolution in Replication

Multimaster replication enables updates to multiple directory servers. Conflicts occur whenever the Oracle directory replication server attempts to apply remote changes from a supplier to a consumer and fails for some reason.

Four kinds of LDAP operations can lead to conflicts:

Levels at Which Replication Conflicts Occur

There are two types of conflicts:

Entry-Level Conflicts

An entry-level conflicts is caused when the Oracle directory replication server attempts to apply a change to the consumer. Such a change could be one of the following types of changes to the consumer:

These conflicts can be difficult to resolve. For instance, it may be impossible to resolve a conflict because:

If an entry exists and it should not, then that may mean:

Attribute-Level Conflicts

An attribute-level conflict is caused when two directories are updating the same attribute with different values at different times. If the attribute is single-valued, then the replication process resolves the conflict by examining the timestamps of the changes involved in the conflict.

Typical Causes of Conflicts

Conflicts usually stem from the timing of changes arising from the occasional slowness or transmission failure over wide-area networks. Also, an earlier inconsistency might continue to cause conflicts if it is not resolved in a timely manner.

Automated Resolution of Conflicts

The Oracle directory replication server attempts to resolve all conflicts that it encounters by following this process:

  1. The conflict is detected when a change is applied.

  2. The replication process attempts to reapply the change a specific number of times or repetitively for a specific amount of time after a specific waiting period.

  3. If the replication process reaches the retry limit without successfully applying the change, then it flags the change as a conflict and moves the change to a low-priority, human intervention queue. Changes are then applied according to the time unit specified in the orclHIQSchedule parameter in the replication agreement. Before it moves the change, the Oracle directory replication server writes the conflict into a log file for the system administrator.

    Note:

    There is no conflict resolution of schema, catalog, and group entries during replication. This is because attempting resolution of such large multi-valued attributes would have a significant negative impact on performance. Be careful to avoid updating such entries from more than one master at a time. 

How Replication Works: An Overview

Figure 2-8 provides a general overview of the replication process on both the supplier and the consumer. It illustrates the following:

On the supplier side:

  1. When an LDAP client issues a directory modification, the LDAP server generates a change log object in the change log object store.

  2. At a scheduled time, the replication server spawns an outbound change log processing thread to translate the change log object into a row--for example, Change entry--in the change log table.

  3. When a change entry gets inserted and then committed to the change log table, ASR immediately copies the change into the deferred transaction queue.

  4. After a scheduled interval, ASR pushes pending transactions from the deferred transaction queue across the network to the consumer change log table.

On the consumer side:

  1. The replication server spawns a change log processing thread for each supplier, based on a scheduled replication cycle.

  2. The change log processing thread consults the change status table for the last change applied from the supplier to the consumer.

  3. It then fetches and applies all the new changes from the change log table to the LDAP server.

  4. After completing the change log processing, the change log processing thread updates the change status table to record the last change applied from the supplier before exiting.

  5. ASR copies the change status update into the deferred transaction queue.

  6. After the scheduled ASR replication interval, ASR pushes pending change status updates from the deferred transaction queue to the supplier change status table.

Figure 2-8 illustrates the replication process.

Figure 2-8 Overview of ASR-Based Replication Architecture


Text Description of oid81001.gif follows
Text description of the illustration oid81001.gif

Although, in Figure 2-8, the roles of supplier and consumer have been separated, in an actual multimaster replication environment, each directory server is both a supplier and a consumer. In such an environment, the purging of entries that are already applied or that have been dropped as candidate changes occurs regularly. Remote change records in the local Changelog table are purged by the garbage collection thread if they have been applied locally. Local change records in the local Changelog table are purged by the garbage collection thread if they have been distributed to all the consumers.

See Also:

  • "How Replication Works: An Overview" for a more detailed explanation of how the replication server adds, deletes, and modifies entries, as well as how it modifies DNs and RDNs

  • "Conflict Resolution in Replication" for a detailed description of how the replication server resolves conflicts when it adds, deletes, and modifies entries and when it modifies DNs and RDNs

 

How Replication Works: A Closer Look

This section describes in more detail than the previous section how the automated replication process adds, deletes, and modifies entries, and how it modifies DNs and RDNs.

How the Replication Process Adds a New Entry to a Consumer

When Oracle directory replication server successfully adds a new entry to a consumer, it follows this change application process:

  1. The Oracle directory replication server looks in the consumer for the DN of the parent of the target entry. Specifically, it does this by looking for a global unique identifier (GUID) assigned to the DN of the parent.

  2. If the parent entry exists, then the Oracle directory replication server composes a DN for the new entry and places the new entry under its parent in the consumer. It then places the change entry in the purge queue.

If the change entry is not successfully applied on the first try:

If the change entry is not successfully applied on all but the last retry:

If the change entry is not successfully applied on the last retry:

Go to previous page Go to next page
Oracle
Copyright © 1996-2000, Oracle Corporation.
All Rights Reserved. | | Ad Choices.

Library
Solution Area
Contents
Index