Release 2.0.6
A77230-01
 Library |
 Product |
 Contents |
 Index |
| Oracle Internet Directory Administrator's Guide Release 2.0.6 A77230-01 |
|
This chapter explains some of the key concepts you need to know when using Oracle Internet Directory. It covers topics in the following sections:
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 Figure 2-1.
The DIT in Figure 2-1 is structured along geographical and organizational lines. It diagrammatically represents entries for two employees who have the same common name (cn), namely, Anne Smith.
The DIT branch on the right represents the entry for the Anne Smith whose common name (cn) is Anne Smith, who works in the organization (o) Acme, in the country (c) of Great Britain (uk), in an organizational unit (ou) named Server Development.
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 entry's full DN--not simply it's RDN. For example, within the global organization in Figure 2-1, there are two employees with the same RDN, namely, Anne Smith. To avoid confusion between these two entries, 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.)
In a typical telephone directory, an entry for a person contains such information items as an address and phone number. In an online directory, such information items are called attributes. Attributes in a typical employee entry could include a job title, e-mail address, and phone number.
In Figure 2-1, the entry for Anne Smith in Great Britain 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-1 is also an entry with attributes, although the attributes for each are not shown.
Each attribute consists of an attribute type and one or more attribute values. The attribute type identifies the kind of information that that attribute contains--for example, jobTitle. The attribute value is the particular instance of information appearing in that entry. For example, in the entry for Anne Smith, the value for the jobTitle attribute could be manager.
Attributes contain two kinds of information.
Any given attribute can hold either application information, or operational information, but not both.
Single-valued attributes carry only one value in the attribute, whereas multi-valued attributes can have more than one value. An example of a multi-valued attribute is a group membership list that includes the names of all the members of a given group, such as an e-mail list. Attributes can be either single-valued or multi-valued.
Oracle Internet Directory implements all of the standard LDAP attributes. Table 2-1 shows some of the more common LDAP attributes.
In addition, Oracle Internet Directory provides several proprietary attributes that are listed in Appendix F.
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 can be printed, whether it has to be in the form of a date, or whether the data can consist of numbers only. Each attribute can have only one syntax attached to it.
Oracle Internet Directory implements all the standard LDAP syntaxes. You cannot add new syntaxes beyond those already supported by Oracle Internet Directory.
In response to most incoming client requests, the directory server performs search and compare operations. During these operations, the directory server consults relevant matching rules 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.
When you define a directory entry, you assign one or more object classes to it. These object classes contain attributes. An object class is a category of objects, and it typically provides both mandatory and optional attributes for particular objects.
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.
Oracle Internet Directory provides standard LDAP object classes, as well as several proprietary object classes, at the time of installation. You cannot add mandatory attributes to the sets of attributes belonging to these pre-defined object classes. If a given object class does not contain all the attributes that you want to store for an entry, then you can use one of the following options:
The remainder of this section discusses object classes in the following subsections:
Appendix F for a list of object classes in the schema installed with Oracle Internet Directory
See Also:
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. For example, in Figure 2-2, the organizationalPerson object class inherits the attributes of the person object class. Entries may inherit the attributes defined by multiple object classes.
As you can also see in Figure 2-2, one special object class, called top, has no superclasses. It is one of the superclasses of every structural object class (discussed in "Object Class Types") in the directory, and its attributes are inherited by every entry.
There are three types of object classes described in the following sections:
These object classes are virtual object classes. An abstract object class cannot be the only object class for an entry. The object class top is an abstract object class. It is required to be 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 object classes in top, and either describes or points to further information about each one.
Most of the object classes that you use are structural object classes, and all entries should belong to one structural object class. Examples of structural object classes are person and groupOfNames. These object classes follow DIT structure rules that specify which kinds of object classes can be created under any given object class. For example, in Figure 2-1, a DIT structure rule might require that all objects that are located below the organization (o) Acme must be organizational units (ou). Following this rule, you could not enter person objects directly below the organization Acme.
These object classes are groupings of attributes that can be used to expand the existing list of attributes in an entry. For example, suppose you have defined an entry as a member of two object classes. If you want that entry to have additional attributes that do not belong to these object classes, you can create a new auxiliary object class that contains the extra attributes, and associate it 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.
All information about how data is organized in the DIT--that is, metadata such as object classes, attributes, matching rules, and syntaxes--is included in what is called the directory schema. This information is stored 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:
Appendix F for a list of both standard and proprietary schema elements installed with Oracle Internet Directory |
Although an online directory is logically centralized, it can physically distribute its data onto several servers. Physical distribution reduces the amount of work a single server would otherwise have to do, and enables the directory to accommodate a larger number of entries.
When physically distributing information, a directory divides its information into units called directory naming contexts. A directory 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.
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.
The following pages discuss both types of directory distribution in the following sections:
This section describes topics in the following subsections:
In addition to improving performance by providing more servers to handle queries, replication also improves reliability by eliminating risks associated with a single point of failure.
|
Note: There are no Internet standards for directory replication yet, though 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. For more on change logs, see "Replication Architecture". |
Each copy of a naming context that is contained within a server is called a replica. A directory server can hold 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 queue, then attempts to apply them at regular, less frequent intervals that you specify.
Figure 2-4 shows a replicated directory.
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 multi-master replication.
Figure 2-5 illustrates a Directory Replication Group in which three nodes share updates with each other in a replication agreement.
In Figure 2-5, 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:
"Step 6: Configure Replication" for information about how to configure replication agreements |
Transport of update information between nodes 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. Directory replication uses this ASR mechanism as a transport vehicle for propagating directory change information across to other directory servers participating in a replication agreement. 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:
|
Replication uses change logs on supplier servers. 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.
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 LDAP-compliant directory server which implements them. The replication process is illustrated in Figure 2-6.
To configure replication, you specify which nodes in a replication group should share changes.
This section provides a general overview of the replication process on both the supplier and the consumer.
On the supplier side:
On the consumer side:
"The Replication Process" for a more detailed explanation of how the replication server adds, deletes, and modifies entries, as well as how it modifies DNs and RDNs
See Also:
Figure 2-6 illustrates the replication process.
Although, in Figure 2-6, the roles of supplier and consumer have been separated, in an actual multi-master replication environment, every directory server is both a supplier and a consumer. In such an environment, garbage collection--that is, the removal 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 deleted by the garbage collection thread if they have been applied locally, and local change records in the local Changelog table are deleted by the garbage collection thread if they have been distributed to all the consumers.
|
See Also:
"Conflict Resolution" for a detailed description of how the replication server resolves conflict when it adds, deletes, and modifies entries and when it modifies DNs and RDNs |
Figure 2-7 shows a partitioned directory in which some naming contexts reside on different servers.
In Figure 2-7, four naming contexts reside on Server A:
Two naming contexts on Server A are replicated on Server B:
The directory uses knowledge references, also called referrals, to locate information that is requested of Server B, but that resides on Server A. Knowledge references provide the names and addresses of the various naming contexts. Server B uses knowledge references to tell clients that Server A has the requested information--in this case, 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-8, two of the naming contexts on Server B have naming contexts that are subordinate to them. 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.
Naming contexts that start at the top of the DIT obviously cannot have a knowledge reference to a superior naming context.
Oracle Internet Directory provides many powerful mechanisms for protecting information from unauthorized access. This section discusses the following elements of directory security:
Authentication is the process by which the directory server establishes the true identity of the user connecting to the directory. Authentication 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 users', hosts', and clients' identities are correctly known, the Oracle Internet Directory provides the three authentication options described in the following sections:
If your directory is available to everyone, then you can allow users to log in to the directory anonymously. In this case, 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.
In this case, the client identifies itself to the server by means of a DN and a password which are sent in the clear over the network. The server verifies that the DN and password sent by the client match the DN and password stored in the directory.
Oracle Internet Directory provides strong authentication 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.
The remainder of this section discusses SSL in the following subsections:
SSL is an industry standard protocol for securing network connections. SSL 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.
You can use SSL in one of three authentication modes. You can require:
The components of SSL include:
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), described more fully in this section. 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.
A certificate authority is a trusted third party that certifies that other entities--users, databases, administrators, clients, servers--are who they say they are. The certificate authority verifies the user'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. 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.
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:
Appendix D for detailed information about managing wallets by using the Oracle Wallet Manager
See Also:
At the beginning of their communication, the client and directory server perform a handshake which includes three important tasks:
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.
See Also:
SSL authentication between a client and a directory server involves three basic steps:
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 (ACI) 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 ACI Items and their format is called the ACI Directive format.
|
See Also:
|
To ensure that data has not been modified, deleted, or replayed during transmission, Oracle Internet Directory requires the use of 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.
To ensure that data is not disclosed during transmission, the Oracle Internet Directory supports two levels of encryption available through SSL:
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.
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.
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 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:
|
This section covers the topics in the following sections:
An Oracle Internet Directory node is implemented as an application running on the Oracle 8i server. To communicate with the database, which may be on the same platform or on a different one, the Oracle Internet Directory uses Net8, Oracle's platform-independent database connectivity solution. This relationship is illustrated in Figure 2-9.
Figure 2-10 shows the various directory server components and their relationships running on a single node.
|
Note: In Figure 2-10, the database is on the same node as the directory server processes. However, since 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-10) includes the following major components:
| Component | Description |
|---|---|
|
LDAP server instance |
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 |
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. See Also: "Distributed Directories", Chapter 10, and Appendix B |
|
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. See Also: "Using OID Control Utility" |
OID Control Utility 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 Internet Directory instance.
|
See Also:
"Configuration Set Entries" for more detailed information about the configuration parameters |
OID Monitor executes the start-server and stop-server requests that you initiate from OID Control Utility. OID Monitor is also responsible for monitoring servers and restarting 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 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's file system.
OID Monitor checks the state of the servers through mechanisms provided by the operating system.
The replication server uses LDAP to communicate with an 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 Internet Directory (LDAP) servers over LDAP.
Each LDAP directory server instance looks similar to what Figure 2-11 illustrates.
The components of the LDAP directory server instance include:
The configuration parameters for each server instance are stored in a configuration set entry, or configset. A configuration set entry is a directory entry holding 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 configsets 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.
For more information on concepts discussed in this chapter, refer to the list of books and online articles below. Most of the entries in the list also contain references to other publications.
Chadwick, David. Understanding X.500 The Directory. Thomson Computer Press, 1996. This book is now out of print, but is available online at: http://www.salford.ac.uk/its024/Version.Web/Contents.htm
Hodges, Jeff, Computing and Communication Services, Stanford University, http://www-leland.stanford.edu/group/networking/directory/x500ldapfaq.html
Howes, Tim and Mark Smith. LDAP: Programming Directory-enabled Applications with Lightweight Directory Access Protocol. Macmillan Technical Publishing, 1997.
Howes, Tim, Mark Smith and Gordon Good, Understanding and Deploying LDAP Directory Services. Macmillan Technical Publishing, 1999.
Kosiur, Dave, LDAP: "The next-generation directory?," SunWorld Online, October 1997.
Radicati, Sara, X.500 Directory Services, Technology and Deployment, International Thomson Computer Press, 1994.
University of Michigan LDAP Repository, http://www.umich.edu/~rsug/ldap/
|
 Copyright © 1999 Oracle Corporation. All Rights Reserved. |
|