Oracle Internet Directory Administrator's Guide Release 2.1.1 Part Number A86101-01 |
Library | Service | Contents | Index

# 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

- Attributes

- Object Classes

- Naming Contexts

- The Directory Schema

- Security

- National Language Support

- Oracle Internet Directory Architecture

- Distributed Directories: An Overview

- Distributed Directories: Replication

- Distributed Directories: Partitioning

- Synchronizing with Other Directories in a Metadirectory Environment

  See Also: "Related Documentation" for suggestions on further reading about LDAP-compliant directories

## 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 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 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

- Single-Valued and Multi-Valued Attributes

- Attribute Options

- Common LDAP Attributes

- Attribute Syntax

- Attribute Matching Rules

### 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:

- Add optional attributes to an existing object class

- Define a new (base) object class

- Define an object subclass

  See Also: Appendix E for a list of object classes in the schema installed with Oracle Internet Directory

This section contains these topics:

- Subclasses, Superclasses, and Inheritance

- Object Class Types

### 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

- Structural

- Auxiliary

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

- orclGuid--Global identification which remains constant if the entry is moved

- creatorsName--See the appropriate IETF documentation.

- createTimestamp--See the appropriate IETF documentation.

- orclACI--See "orclACI"

- orclEntryLevelACI--See "orclEntryLevelACI".

#### 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 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: Chapter 6, "Managing the Directory Schema." Appendix E for a list of both standard and proprietary schema elements installed with Oracle Internet Directory

## Security

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

This section contains these topics:

- Authentication: Ensuring that the identities of users, hosts, and clients are correctly validated

- Access Control and Authorization: Ensuring that a user reads or updates only the information for which that user has privileges

- Data Integrity: Ensuring that data is not modified during transmission

- Data Privacy: Ensuring that data is not disclosed during transmission

- Password Encryption: Ensuring protection of user passwords through any of four encryption options

### 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:

- Certificate

  A certificate ensures that the entity's identity information is correct and that the public key actually belongs to that entity. A certificate is created when an entity's public key is signed by a trusted identity, that is, a certificate authority (CA). A certificate contains the entity's name, public key, serial number, and expiration date. It may contain information about the privileges associated with the certificate. Finally, it contains information about the CA that issued it. A certificate is valid until it expires or is revoked.

- Certificate Authority (CA)

  A certificate authority is a trusted third party that certifies that other entities are who they say they are. The certificate authority verifies the entity's identity and grants a certificate, signing it with the certificate authority's private key.

  Different CAs may have different identification requirements when issuing certificates. For example, one certificate authority may want to see a user's driver's license, another may want the certificate request form to be notarized, yet another may want fingerprints of the person requesting a certificate. The certificate authority publishes its own certificate which includes its public key.

  Each network entity has a list of the certificates of the CAs it trusts. Before communicating with another entity, a given entity uses this list to verify that the signature on the other entity's certificate is from a trusted CA. Network entities can obtain their certificates from the same or from different CAs.

- Wallet

  A wallet is an abstraction used to store and manage authentication data such as keys, certificates, and trusted certificates, also called trustpoints, which are needed by SSL. In an Oracle environment, each system using SSL has a wallet with an X.509 version 3 certificate, private key, and list of trusted certificates.

  Security administrators use the Oracle Wallet Manager to manage security credentials on the server. Wallet owners use it to manage security credentials on clients. Specifically, the Oracle Wallet Manager is used to do the following:

  - Generate a public/private key pair and create a certificate request for submission to a certificate authority

  - Install a certificate for the entity

  - Configure trusted certificates for the entity

    See Also: Appendix C for detailed information about managing wallets by using the Oracle Wallet Manager

##### The SSL Handshake

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

- The client and server establish which cipher suite to use. A cipher suite is a set of authentication, encryption, and data integrity algorithms used for exchanging messages between network nodes. During an SSL handshake, the two nodes negotiate to see which cipher suite they will use when transmitting messages back and forth.

- The server sends its certificate to the client. The client verifies that the directory server's certificate was signed by a trusted CA.

  Similarly, if client authentication is required, the client sends its own certificate to the directory server. The directory server verifies that the client's certificate was signed by a trusted CA.

- The client and directory server exchange key material using public-key cryptography, and, from this material, they each generate a session key. All subsequent communication between client and directory server is encrypted and decrypted by using this set of session keys and the negotiated cipher suite.

  See Also: "Data Integrity: Ensuring that data is not modified during transmission" for more information on data integrity and encryption "Supported Cipher Suites" for a list of SSL cipher suites supported in Oracle Internet Directory

##### 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: Chapter 8, "Managing Secure Sockets Layer (SSL)" Chapter 9, "Managing Directory Access Control" for instructions on setting access control policies Appendix C, "Using Oracle Wallet Manager" for a discussion of certificates and wallets

### 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: Chapter 9, "Managing Directory Access Control" for instructions on setting access control policies Appendix D, "Using Access Control Directive Format" for instructions on correctly formatting ACI directives

### 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:

- DES40

  The DES40 algorithm, available internationally, is a variant of DES in which the secret key is preprocessed to provide forty effective key bits. It is designed for use by customers outside the USA and Canada who want to use a DES-based encryption algorithm. This feature gives commercial customers a choice in the algorithm they use, regardless of their geographic location.

- RC4_40

  Oracle has obtained license to export the RC4 data encryption algorithm with a 40-bit key size to virtually all destinations where other Oracle products are available. This makes it possible for international corporations to safeguard their entire operations with fast cryptography.

  See Also: Chapter 8, "Managing Secure Sockets Layer (SSL)" for more information about 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:

- No Encryption

- MD5--An improved, and more complex, version of MD4

- SHA--Secure Hash Algorithm, which produces a 160-bit hash, longer than MD5. The algorithm is slightly slower than MD5, but the larger message digest makes it more secure against brute-force collision and inversion attacks.

- UNIX Crypt--The UNIX encryption algorithm

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" for information on the main Oracle Internet Directory components Chapter 12, "Managing National Language Support (NLS)" for instructions on using NLS in Oracle Internet Directory Oracle8i National Language Support Guide

for a detailed discussion of NLS

## Oracle Internet Directory Architecture

This section contains these topics:

- An Oracle Internet Directory Node

- An Oracle Directory (LDAP) Server Instance

- Configuration Set Entries

- Example: How Oracle Internet Directory Works

### 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:

- The OID Control Utility

- The LDAP Server Instance 1 non-SSL port 389

- The LDAP Server Instance 2 SSL Enabled port 636

- The OID Monitor

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

- Oracle Directory Manager

- Oracle directory replication server

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 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 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: "Managing Server Configuration Set Entries" "Configuration Set Entry Attributes" for a list of configuration set entry attributes

## 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" "Distributed Directories: Partitioning"

## 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 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

- Oracle Advanced Symmetric Replication (ASR)

- Replication Architecture

- Change Log Purging

- Conflict Resolution in Replication

- How Replication Works: An Overview

- How Replication Works: A Closer Look

  See Also: Chapter 10, "Managing Directory Replication" for more information on replication

### 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 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: "Oracle Directory Replication Server Parameters" "Viewing and Modifying Replication Configuration Parameters by Using Oracle Directory Manager" "Modifying Replication Configuration Parameters by Using Command Line Tools"

### 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:

- Addition

- Deletion

- Modification

- Modification of either an RDN or a DN

#### Levels at Which Replication Conflicts Occur

There are two types of conflicts:

- Entry-level conflicts

- Attribute-level 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:

- Adding an entry that already exists

- Deleting an entry that does not exist

- Modifying an entry that does not exist

- Applying a modifyrdn operation when the DN does not exist

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

- The entry has been moved to a different location

- The entry has not yet arrived from a supplier

- The entry has been deleted

- The entry never existed

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

- The entry was added earlier

- The entry recently underwent a modifydn operation

##### 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 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:

The Oracle directory replication server places the new change entry in the retry queue, sets the number of retries to the configured maximum, and repeats the change application process.

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

The Oracle directory replication server keeps the change entry in the retry queue, decrements the number of retries, and repeats the change application process.

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

The Oracle directory replication server checks to see if the new entry is a duplicate of an existing entry.

If the change entry is a duplicate entry:

The Oracle directory replication server applies the following conflict resolution rules:

- The entry with the older creation time stamp is used.

- If both entries have the same creation time stamp, then the entry with the smaller GUID is used.

If the change entry is used, then the target entry is removed, the change is applied, and the change entry is placed in the purge queue.

If the target entry is used, then the change entry is placed in the purge queue.

If the change entry is not a duplicate entry:

The Oracle directory replication server places the change entry in the human intervention queue, and repeats the change application process at the interval you specified in the `orclHIQSchedule` parameter.

If the change entry is not successfully applied after it has been placed in the human intervention queue:

The Oracle directory replication server keeps the change in this queue, and repeats the change application process at specified intervals while awaiting action by the administrator. The administrator can use the OID reconciliation tool and the human intervention queue manipulation tool to resolve the conflict.

#### How the Replication Process Deletes an Entry

When the Oracle directory replication server deletes an entry from a consumer, it follows this change application process:

1. The Oracle directory replication server looks in the consumer for an entry with a GUID matching the one in the change entry.

2. If the matching entry exists in the consumer, then the Oracle directory replication server deletes it. It then places the change entry in the purge queue.

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

The Oracle directory replication server places the change entry in the retry queue, sets the number of retries to the configured maximum, and repeats the change application process.

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

The Oracle directory replication server keeps the change entry in the retry queue, decrements the number of retries, and repeats the change application process.

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

The Oracle directory replication server places the change entry in the human intervention queue and repeats the change application process at specified intervals.

If the change entry is not successfully applied after it has been placed in the human intervention queue:

The Oracle directory replication server keeps the change entry in this queue, and repeats the change application process at specified intervals while awaiting action by the administrator. The administrator can use the OID reconciliation tool and the human intervention queue manipulation tool to resolve the conflict.

#### How the Replication Process Modifies an Entry

When the Oracle directory replication server modifies an entry in a consumer, it follows this change application process:

1. The Oracle directory replication server looks in the consumer for an entry with a GUID matching the one in the change entry.

2. If the matching entry exists in the consumer, then the Oracle directory replication server compares each attribute in the change entry with each attribute in the target entry.

3. The Oracle directory replication server then applies the following conflict resolution rules:

   1. The entry with the most recent modify time is used.

   2. The entry with the most recent version of the attribute is used.

   3. The modified attribute on the host whose name is closest to the beginning of the alphabet is used.

4. The Oracle directory replication server applies the filtered modification, and places the change entry in the purge queue.

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

The Oracle directory replication server places the change entry in the retry queue, sets the number of retries to the configured maximum, and repeats the change application process.

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

The Oracle directory replication server keeps the change entry in the retry queue, decrements the number of retries, and repeats the change application process.

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

The Oracle directory replication server places the change entry in the human intervention queue and repeats the change application process at specified intervals.

If the change entry is not successfully applied after it has been placed in the human intervention queue:

The Oracle directory replication server keeps the change entry in this queue, and repeats the change application process at specified intervals while awaiting action by the administrator. The administrator can use the OID reconciliation tool and the human intervention queue manipulation tool to resolve the conflict.

#### How the Replication Process Modifies a Relative Distinguished Name

When the Oracle directory replication server modifies the RDN of an entry in a consumer, it follows this change application process:

1. The Oracle directory replication server looks in the consumer for the DN with a GUID that matches the GUID in the change entry.

2. If the matching entry exists in the consumer, then the Oracle directory replication server modifies the RDN of that entry and places the change entry in the purge queue.

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

The Oracle directory replication server places the change entry in the retry queue, sets the number of retries to the configured maximum, and repeats the change application process.

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

The Oracle directory replication server keeps the change entry in the retry queue, decrements the number of retries, and repeats the change application process.

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

The Oracle directory replication server places the change entry in the human intervention queue and checks to see if it is a duplicate of the target entry.

If the change entry is a duplicate entry:

The Oracle directory replication server applies the following conflict resolution rules:

- The entry with the older creation time stamp is used.

- If both entries have the same creation time stamp, then the entry with the smaller GUID is used.

If the change entry is used, then the target entry is removed, the change entry is applied, and then placed in the purge queue.

If the target entry is used, then the change entry is placed in the purge queue.

If the change entry is not a duplicate entry:

The Oracle directory replication server places the change entry in the human intervention queue, and repeats the change application process at specified intervals.

If the change entry is not successfully applied after it has been placed in the human intervention queue:

The Oracle directory replication server keeps the change entry in this queue, and repeats the change application process at specified intervals while awaiting action by the administrator. The administrator can use the OID reconciliation tool and the human intervention queue manipulation tool to resolve the conflict.

#### How the Replication Process Modifies a Distinguished Name

When the Oracle directory replication server modifies the DN of an entry in a consumer, it follows this change application process:

1. The Oracle directory replication server looks in the consumer for the DN with a GUID that matches the GUID in the change entry.

   The Oracle directory replication server also looks in the consumer for the parent DN with a GUID that matches the GUID of the new parent specified in the change entry.

2. If both the DN and the parent DN of the target entry exist in the consumer, then the Oracle directory replication server modifies the DN of that entry and places the change entry in the purge queue.

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

The Oracle directory replication server places the change entry in the retry queue, sets the number of retries to the configured maximum, and repeats the change application process.

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

The Oracle directory replication server keeps the change entry in the retry queue, decrements the number of retries, and repeats the change application process.

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

The Oracle directory replication server places the change entry in the human intervention queue and checks to see if it is a duplicate of the target entry.

If the change entry is a duplicate entry:

The Oracle directory replication server applies the following conflict resolution rules:

- The entry with the older creation time stamp is used.

- If both entries have the same creation time stamp, then the entry with the smaller GUID is used.

If the change entry is used, then the target entry is removed, the change entry is applied, and then placed in the purge queue.

If the target entry is used, then the change entry is placed in the purge queue.

If the change entry is not a duplicate entry:

The Oracle directory replication server places the change entry in the human intervention queue, and repeats the change application process at specified intervals.

If the change entry is not successfully applied after it has been placed in the human intervention queue:

The Oracle directory replication server keeps the change entry in this queue, and repeats the change application process at specified intervals while awaiting action by the administrator. The administrator can use the OID reconciliation tool and the human intervention queue manipulation tool to resolve the conflict.

## Distributed Directories: Partitioning

Partitioning is another way of distributing directory information. Figure 2-9 shows a partitioned directory in which some naming contexts reside on different servers.

#### Figure 2-9 A Partitioned Directory

Text description of the illustration oid81010.gif

In Figure 2-9, four naming contexts reside on Server A:

- `dc=acme,dc=com`

- `c=us`

- `c=uk`

- `c=au`

Two naming contexts on Server A are replicated on Server B:

- `dc=acme,dc=com`

- `c=au`

The directory uses knowledge references, also called referrals, to locate information that is requested of Server B, but that resides on Server A.

### About Knowledge References (Referrals)

Knowledge references provide the names and addresses of the various naming contexts. In Figure 2-9, Server B uses knowledge references to tell clients that Server A has the requested information in the c=us and c=uk naming contexts. Clients can then use the referral information to contact Server A.

Typically, each directory server contains both superior and subordinate knowledge references. Superior knowledge references point upward in the DIT toward the root. They tie the partitioned naming context to its parent. Subordinate knowledge references point downward in the DIT to other partitions.

For example, in Figure 2-10, Server B holds two naming contexts, each of which is superior to other naming contexts. These two superior naming contexts use subordinate knowledge references to point to their subordinate naming contexts. Conversely, the naming context on Server A has an immediate superior residing on Server B. Server A therefore uses a superior knowledge reference to point to its parent on Server B.

#### Figure 2-10 Using Knowledge References to Point to Naming Contexts

Text description of the illustration concept8.gif

Naming contexts that start at the top of the DIT obviously cannot have a knowledge reference to a superior naming context.

Note: There are presently no Internet standards for enforcing the validity of knowledge references, and Oracle Internet Directory does not do so. It is up to the administrator to ensure consistency among knowledge references within an enterprise network. Oracle Corporation recommends that permission for managing knowledge reference entries be restricted like any other privileged administrative function such as schema or access control.

### Kinds of Knowledge Reference

There are two kinds of knowledge reference:

Smart knowledge reference | Returned when the knowledge reference entry is in the scope of the search. It points the user to the server that stores the requested information. For example, suppose that: Server A holds the naming context `ou=server development,c=us,o=acme`, and has a knowledge reference to Server B Server B holds the naming context `ou=sales,c=us,o=acme` When a user sends a request to Server A for information in `ou=sales,c=us,o=acme`, Server A provides the user with a knowledge reference pointing to Server B.
Default knowledge reference | Returned when the base object is not in the directory, and the operation is performed in a naming context not held locally by the server. A default knowledge reference typically sends the user to a server that has more knowledge about the directory partitioning arrangement. For example, suppose that Server A holds: The naming context `c=us,o=acme` A knowledge reference to Server PQR that has more knowledge about the overall directory partitioning arrangement Now suppose that a client requests information on `c=uk,o=acme`. When Server A finds that it does not have the `c=uk,o=acme` naming context, it points the user to Server PQR. From there, the user can find the server holding the requested naming context.

See Also: "Managing Knowledge References (Referrals)"

## Synchronizing with Other Directories in a Metadirectory Environment

In a metadirectory environment, you can synchronize multiple directories with Oracle Internet Directory to form a single virtual directory. This section contains these topics:

- About Metadirectories

- How Oracle Internet Directory Works with a Metadirectory Solution

### About Metadirectories

A metadirectory enables enterprises to synchronize many directories into one "virtual" directory.

Enterprises today often deploy multiple "directories," such as ERP systems, database applications, messaging systems, and Network Operating Systems (NOS). Managing so many different directories can cause problems:

- Redundancy--The same information is represented in many different places in the enterprise.

- High cost of administration--Administrators must maintain essentially the same information in many different places.

- Inconsistent data--Updated information in one directory is not shared with all the other directories.

A metadirectory addresses these problems by integrating all these enterprise directories into one synchronized directory of directories.

### How Oracle Internet Directory Works with a Metadirectory Solution

Oracle Internet Directory release 2.1.1 is interoperable with supported third party metadirectory solutions. This allows various information repositories to synchronize with Oracle Internet Directory and to form a single virtual directory.

A metadirectory solution incorporating Oracle Internet Directory allows:

- Data to be imported from other information repositories, called connected directories, into Oracle Internet Directory

- Data to be exported from Oracle Internet Directory into connected directories

The import and export of data between Oracle Internet Directory and connected directories are performed by software components called metadirectory agents. Metadirectory vendors provide these as part of their metadirectory solutions. You can also design them by using a metadirectory vendor's framework.

For example, for each employee in an enterprise, Oracle Internet Directory, interoperating with a metadirectory solution, can build a global directory entry. That entry can contain data from such different sources as Human Resources applications, email services, or NOS databases. Users can then access that entry, knowing that it is up-to-date and synchronized among all connected directories.

Moreover, the synchronization can respect the existing data ownership policies--for example, only the Human Resource Directory may be privileged to change an employee's salary attribute. In this way, the metadirectory solution manages directory data and shares information across different directories in an enterprise.

Note: Oracle Internet Directory release 2.1.1 is interoperable with the supported version of Siemens DirXMetahub. Oracle Corporation neither licenses the Siemens DirXMetahub product nor ships it on the CD you receive. To obtain the Siemens DirXMetahub, contact Siemens directly at: `http://www.usa.siemens.com/`

A supported metadirectory solution uses Oracle Internet Directory as its metadirectory store--that is, Oracle Internet Directory is the enterprise directory against which other application-specific connected directories are synchronized.

Integrating other directories with Oracle Internet Directory through a metadirectory solution provides these benefits:

- Consistency, data integrity, and better quality of information for both users and applications

- A single point of access for all directory data through standards-based clients like Web browsers, reduced administrative costs, and ease of administration

- A single point of administration using the Oracle Internet Directory management tool

- The ability to keep all connected directories in the environment up-to-date

Oracle Internet Directory support for a metadirectory solution allows these types of directory synchronization:

- Complete and incremental import from connected directories into Oracle Internet Directory (add, modify, and remove operations)

- Complete and incremental export from Oracle Internet Directory into connected directories (add, modify, and remove operations)

  See Also: Chapter 11, "Synchronizing with Multiple Directories"

| Copyright © 1996-2000, Oracle Corporation. All Rights Reserved. |
Library | Service | Contents | Index