Oracle9i LDAP: Advanced Configuration of Directory Naming

Oracle9i LDAP: Advanced Configuration of Directory Naming

Product Area: Database

Oracle9i LDAP: Advanced Configuration of Directory Naming

Daniel T. Liu, Senior DBA
First American Real Estate Solutions

Introduction

Oracle Net enables services and their applications to reside on different computers and communicate as peer applications. Network information is stored in multiple places and in multiple formats. The main function of Oracle Net is to establish network sessions and transfer data between a client machine and a server or between two servers. There are different resolution methods used by Oracle Net to resolve a name and help a client to locate a database. The most common practice is storing net service names in a local naming configuration file called tnsnames.ora. But this method becomes a maintenance nightmare for the network and database administrators in a dynamic and multi-platform environment.

OID (Oracle Internet Directory) provides a new mechanism of resolving net service names by storing database-connecting information in a LDAP (Lightweight Directory Access Protocol) Server. LDAP-based name resolution is considered an industry-standard as compare to the more proprietary Oracle Names Server. The OID also replaces the need for storing connecting information on each individual client machine. This solution reduces the cost of maintenance by 50-95% depending on the number of databases and the topology of the network.

This paper discusses the required steps to install, configure and setup an Oracle Internet Directory Server for name resolution. It offers an introduction to the basic concepts of OID and Oracle Net. It shows how to use Oracle Net administration tools, such as Oracle Directory Manager, Net Configuration Assistant and Net Assistant, to configure ldap.ora, listener.ora, sqlnet.ora and tnsnames.ora files. It also shows how to use command line utilities, such as "oidmon" and “oidctl” to start and stop OID Monitor and OID server instance. This paper also discusses the process of migrating from Local Naming and Oracle Names to LDAP directory.

Net Services Basics

Oracle Net Services provide enterprise wide connectivity solutions in distributed, heterogeneous computing environments. It consists the following major components:

Net Services client

Net Services Client enables client connections to databases across a network. A client-side application sends a request to Oracle Net Services to be transported across the network to the server.

Net Service Server

Net Services Server enables the listener, through a protocol, to accept connections from client application on the network.

Oracle Net

Oracle Net is a software layer that resides on the client and the Oracle database server. It is responsible for establishing and maintaining the connection between the client application and server, as well as exchanging messages between them, using industry-standard protocols. Oracle Net is comprised of two software components:

Oracle Net Foundation Layer

Oracle Net Foundation Layer provides a standard method for a client application to establish and maintain communication with the Oracle database server on top of industry-standard network protocol.

Oracle Protocol Support

Oracle supports the following protocols:

TCP/IP – the de facto standard Ethernet protocol used for client/server communication over a network. This protocol is used in Unix and NT environments.

TCP/IP with SSL – Oracle Advanced Security is required in order to use TCP/IP with Secure Sockets Layer. SSL stores authentication data in an Oracle Wallet. When the client initiates a Oracle Net connection to the server, SSL performs a handshake between the two using the certificate or the private key.

Named Pipes – is a high-level interface providing inter-process communications between clients and server and is specifically designed for PC LAN environments.

LU6.2 – the Logical Unit Type 6.2 protocol is part of the IBM Advanced Program-to-Program Communication architecture.

VI – The Virtual Interface (VI) protocol can be used for application Web server and database server communication. It is the de facto standard protocol for cluster server environment, and is more efficient than TCP/IP.


Listener

OracleWorld 2003, Paper #36576 / Page 1 of 17

Product Area: Database

The listener is a separate process that resides on the database server. It receives incoming client connection requests and manages the traffic of these requests to the server.

A listener is configured with one or more listening protocol addresses and service information about the destination service. Service information may or may not be configured in the listener.ora file.

OracleWorld 2003, Paper #36576 / Page 1 of 17

Product Area: Database

Oracle7 or Oracle8 release 8.0 requires service configuration in the listener.ora file. Oracle8i and Oracle9i have a feature called service registration, which automatically registers information with the listener and does not require configuration in the listener.ora file.

The listener has a default name of LISTENER and is configured to listen on the following default protocol addresses:

  • TCP/IP protocol on port 1521
  • IPC protocol – for external procedures

A listener can listen for one or more databases either on the same database server or on different servers. One listener can also listen for different versions of databases.

In practice, it is always a good idea to have at least one listener for each version of database on each system and name the listener to some meaningful name instead of the default.

Anytime the listener.ora is modified, the listener must be either reloaded or stopped/re-started with the LSNRCTL utility.

If you expect the listener to handle large volumes of connection requests, you may specify a queue for the process. This enables the listener to dynamically handle larger numbers of concurrent connection requests.

Making the Connection

When a user connects to a database service from across the network, a connect descriptor containing network information about the destination service is passed to the listener. The listener, through a protocol, accepts the client connection. It compares the client information with the information it has received from the database, as well as information it has stored in its own configuration file, listener.ora. If the information matches, a connection is granted.

Direct Connecting Method

One method is to create a lengthy connect string as follow:

Connect scott/tiger@(description =

(address = (protocol = tcp)

(host=dallas.company.com)

(port=1521))

(connect_data = (service_name=db1.company.com)))

In-Direct Connecting Method

A more common way is through use of a net service name, another name for the service, which maps to a connect descriptor to avoid a lengthy connect string:

connect scott/tiger@db1


Oracle Net uses this simple name, call a connect identifier, to identify a connect descriptor. When a net service name is used, connection processing takes place by first mapping the connect identifier to the connect descriptor. This mapped information is stored in one or more repositories of information that are accessed with namingmethods.

Naming Methods

Local Naming

Local naming stores net service names and their connect descriptors in a localized configuration file named tnsnames.ora.

Tnsnames.ora is the configuration file resides on the client’s ORACLE_HOME/network/admin/ directory. This file provides information on the database service name, the network route to the service, including the location of the listener through a protocol address.

Host Naming

Host naming enables users to connect to an Oracle database by using a host name alias. Host names are mapped to the database server’s global database name in an existing names resolution service, such as DNS (Domain Name System), or a centrally maintained set of /etc/hosts files.

External Naming

External naming stores net services names and their connect descriptors in a supported non-Oracle, third-party naming service, such as NIS (Network Information Service) External Naming.

Oracle Names

Oracle Names uses Oracle proprietary software to store the names and addresses of all database services on a network. Clients wishing to connect to a database server direct their connect requests to an Oracle Names Server. Oracle Names Servers resolve the name to a network address and return that information to the client. Oracle9i will be the terminal release of Oracle Names.

Directory Naming

Directory Naming stores net service names and database service names in a centralized LDAP-compliant directory server to access a database service. Today, network information is stored in multiple systems and in multiple formats. With new requirements for Internet computing and new e-business technologies, there is a growing need for a common infrastructure to serve as a foundation for management and configuration of all data and resources in the network. This kind of infrastructure reduces the cost of managing and configuring resources in heterogeneous networks. Oracle strongly recommend storing net service names in the new industry-standard Directory, such as Oracle Internet Directory, to take advantage of superior features in Oracle8i and significant enhancements in Oracle9i.

In order to setup a Directory Naming using Oracle Internet Directory, we first need to understand the basic concept and architecture of Directory, LDAP and Oracle Internet Directory.

Oracle Internet Directory (OID) Basics

Directory

A directory is a specialized database that stores and retrieves collections of information. Such information can represent any resources that require management: employee information, information about shared network resources, or information about database service name. Although a directory is a database, it is not a relational database. A directory has the following characteristics:

  • Primarily read-focused
  • Designed to handle relatively simple transactions on relatively small units of data
  • Designed to be location-independent
  • Designed to store information in entries

LDAP

LDAP stands for Lightweight Directory Access Protocol. It is a standard, extensible directory access protocol. LDAP was conceived as an Internet-ready, lightweight implementation of the International Standardization Organization X.500 standard for directory services. The LDAP standard simplifies management of directory information in three ways:

  • It provides all users and applications in the enterprise with a single, well-defined, standard interface to a single, extensible directory service.
  • It reduces the need to enter and coordinate redundant information in multiple services scattered across the enterprise.
  • Its well-defined protocol and interfaces make it more practical to deploy Internet-ready applications that leverage the directory.

OID

OID stands for Oracle Internet Directory. It is a general-purpose directory service that enables fast retrieval and centralized management of information about dispersed users and network resources. OID is a full-featured LDAP Version 3 compliant directory service implemented as an application on the Oracle8i and Oracle9i database. Its top 3 benefits includes:

  • Scalability – exploits the strengths of Oracle9i, enabling support for terabytes of directory information.
  • High Availability – is designed to meet the needs of a variety of important applications such as multi-master replication between directory servers and fast recover from system failures.
  • Security – offers comprehensive and flexible access control.

Oracle Internet Directory’s unique strength makes it an ideal candidate for central name resolution. Its industry-standard protocol provides greater advantage over the more proprietary Oracle Names Server.

OID Terminology

Entries - each collection of information about an object in a directory is called an entry.

DN - each entry in a directory is uniquely identified by a distinguished name.

DIT - the distinguished name tells exactly where the entry resides in the directory's hierarchy. A Directory Information Tree represents this hierarchy.

RDN - the lowest component of a distinguished name is called the relative distinguished name.

Attributes - the information about an entry in the directory is called attributes.

Object Classes - An object class is a group of attributes that define the structure of an entry. At installation, Oracle Internet Directory provides standard LDAP object classes.

Directory Schema - The directory schema contains all information about how data is organized in the DIT (Meta data such as an object class, an attribute, a matching rule, and syntax).


Naming Contexts - A naming context is a subtree that resides entirely on one server. It must be contiguous, begin at an entry that serves as the top of the subtree and extends downward to either leaf entries or references to subordinate name contexts.

The figure below shows an Information Directory Tree of XYZ Company:

To better understand those OID terminologies, let's look at the figure above. It represents a Directory Information Tree for a 'XYZ Company'. Start from the root node, each node in the tree is an entry. Each entry in the directory is identified by a distinguished name, which tells you exactly where the entry resides in the directory's hierarchy. For example: the DN for entry "John" is: cn=John, ou=manufacturing, c=us, o=xyz company (cn for common name, ou for organization unit, c for country, and o or organization). Within a distinguished name, the lowest component is called relative distinguished name. The RDN for John's DN is John. Information about John such as telephone number, email address, job title, salary, employee ID is called attributes. An employee’s object class can present this collection of employee’s information structure. All the information about how data is organized in the DIT is stored in a directory schema. A naming context can represent a subtree of the DIT, such as employee Dan works in Marketing Department.

OID Architecture

An Oracle Internet Directory node consists of the following major components:

Oracle Directory Server Instance - also called either LDAP server instance or directory server instance. An OID instance comprises one OID listener/dispatcher process listening at a specific TCP/IP port, and one or more Oracle directory server processes. Each LDAP server node can contain more than one OID instances.

OID Monitor - it initiates, monitors, and terminates the LDAP server processes. It checks the state of the servers through mechanisms provided by the operating system. The activity logs are stored at $ORACLE_HOME/ldap/log/oidmo.log.

OID Control Utility (OIDCTL) - communicates with OID Monitor by placing message data in OID server tables. This message data includes configuration parameters required to run each OID instance.

Oracle9i Database - stores the directory data.


How Net Services Use a Directory Server?

To comprehend how net services use a directory server, we must first understand how net service names are stored in an Oracle Internet Directory.

As showed in figure 6, directory information is stored in an Oracle database. In order to bring up a LDAP server instance, we must first create an OID repository database. Once the OID database is up and running, we need to create the OID schema. The OID schema includes two database users: 'ods' and 'odscommon'. The 'ods' user contains 47 tables, which holds the meta data information of the Oracle Directory structure; Oracle Directory Server connects to OID database as 'odscommon' user.

In the directory server, information is organized and stored in the format of directory information tree (DIT). To store net service information, we need to create a DIT subtree structure that either match the existing domain structure used with our tnsnames.ora, or an entirely different structure in which a net service client can recognize. The next step is to create an Oracle Context under each DIT location. The Oracle Context has a relative distinguished name (RDN) of (cn=OracleContext). The Oracle Context stores network object entries, as well as other entries for other Oracle components. The net service name is usually the entry under Oracle Context entry. All the net service attributes (such as host name, port number and service name) are stored in the entry below Oracle Context.


When a net services client connect to a database via Directory Naming, it will first connect to OID server. The OID server connects to the OID database. It searches net service connecting information from the directory tree. Net services information is retrieved and returned to the client. The client is now able to contact the proper listener and connects to the right database (see figure 7).

Step-by-Step Setup of Oracle Internet Directory for Names Resollution

The following eight steps show how to setup Oracle Internet Directory Server in the “company.com” network domain:

Step #1: Planning the Network

  1. Understanding the different version of Oracle Internet Directory.
  • Oracle Internet Directory 2.0.6 is the first release of Oracle LDAP server and it comes with Oracle 8.1.6. Therefore, it would not support name resolution method for client running Oracle release prior to 8.1.6.
  • OID store its directory information in an Oracle database. The OID repository database version has to match with its Oracle Internet Directory server as table listed below:

Oracle Internet Directory / Database Version for OID Repository
2.0.6 / 8.1.6
2.1.1 / 8.1.7
3.0.1 / 9.0.1
  1. Examine company’s existing Oracle network environment.
  • List of all the network domains
  • Oracle database servers within each domain
  • Oracle Instances and listeners running on each server
  • Number of Oracle clients
  1. Planning the Directory Tree
  • Let’s assume that we are working with a single domain called “company.com”.
  • Six Oracle instances are registered under “company.com” domain.


Step #2: Installing Oracle Internet Directory Software

OracleWorld 2003, Paper #36576 / Page 1 of 17

Product Area: Database

For simple illustration, let us assume we are performing a new installation and creating a new OID database on the same server. The complete installation will include step 2, 3 and 4.