ABSTRACT

This technical white paper gives an overview of directory and LDAP, and Net8 functionality in general. It then illustrates the challenges facing Oracle networking management today, such as frequent addition of clients and services; relocation of services; and changing client profiles. Subsequently it introduces the highlights of Net8 directory naming and explains how this feature addresses these challenges, provides efficient management of network resources and Internet customer information. The paper then details the migration procedures from Oracle Names and TNSNAMES.ORA file to LDAP directory naming. The paper finally concludes with a strong recommendation to move to LDAP to take advantage of superior features in Oracle Internet Directory in both Oracle8i and Oracle9i.

ABOUT DIRECTORIES AND THE LDAP V3 STANDARD
Network information is usually stored in multiple systems and multiple formats. With new requirements of 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 on the network. Moving towards such a common infrastructure tends to reduce the cost of managing and configuring resources in heterogeneous networks and, thereby, lower the total cost of ownership (TCO).

A directory service provides a key part of this common foundation, by providing a centralized vehicle for managing and configuring distributed, heterogeneous networks. The network directory becomes the central repository for all "meta-data" about databases, network components, user and corporate policies and preferences, replacing localized files on the clients and servers themselves. Administrators (or those they delegate to) can then manage these objects in one virtual, federated directory; all systems on the heterogeneous network can refer to a single "directory cloud" for needed location, authentication, and authorized user information.

While the value of directory services is well understood, most organizations today are not looking for another directory service to deploy in their environments due to the huge number of directory services they already have. The same piece of information tends to be represented in many different ways in multiple enterprise directories. This translates to a high cost of ownership, as administrators must input and maintain essentially the same information in many different places. There is cost and potential security concerns associated with some of this information being incomplete, inaccurate, or out of synch.

Another problem occurs when organizations look at deploying Internet-ready applications. Organizations are facing security concerns such as how to expose only the information they want to, as well as access control. Unfortunately, decentralized, incompatible directory services do not make it easy to articulate and enforce security policies across the deployed applications and their namespaces.

LDAP represents the emerging solution to both of these problems. LDAP stands for "Lightweight Directory Access Protocol" and is an Internet-ready, lightweight implementation of the ISO X.500 directory standard. One major feature of the LDAP specification is that it requires a minimal amount of networking software on the client side, making it particularly attractive for Internet-based, "thin client" applications. LDAP has rapidly emerged as critical infrastructure for network security and as a vital platform for enabling integration among applications and services on the network.

LDAP simplifies management of directory information considerably. By providing all users and applications in the enterprise with a single, well-defined standard interface to a single, extensible directory service, rapid development and deployment of directory-enabled applications become much easier. In addition, administration of the information becomes much less costly as the need to enter and coordinate redundant information in a wide variety of different places is reduced. Finally, LDAP's well-defined wire protocol and array of programmatic interfaces make deployment of Internet-ready applications that leverage the directory practical.

There are several major LDAP-compliant directories available in the market today, such as, Oracle Internet Directory (OID), Microsoft Active Directory, Novell Directory Service, and Netscape Directory Server. However, most LDAP-compliant directories still cannot interoperate with each other since LDAP v3, the most recent version of this protocol, does not fully standardize some key areas such as access control, replication, and schema design. Oracle continues its strong support of the LDAP v3 standardization process through cross-vendor organizations and initiatives such as the IETF, DMTF, DIF, DSML, and the Open Group.

CHALLENGES FACING ORACLE NETWORKING MANAGEMENT

In the past, administering an Oracle network typically involved using Oracle Network Manager (for SQL*NET networks) or Oracle Net8 Assistant (for Net8 networks) to generate configuration files, and then distributing these files to the various clients and servers in the network. In a relatively static environment, this administrative burden was manageable. However, managing the kind of dynamic environment created by the Internet is another story. To get an idea of the scope of this management challenge, we will now examine in detail some of the administrative tasks required in a dynamic network and illustrate the need for solutions to administer a dynamic network.

INITIAL SETUP AND CONFIGURATION

This is the first required task for deploying a network of Oracle clients and servers at a site. To make a new service available for Net8 connectivity, the system administrator must configure a server process called a "listener." A listener is a network entity that waits for a client request to connect to a specific database service. When using local naming, client-side configuration files contain the names and network addresses of the various listeners in the network. The major administrative task in this instance consists of generating configuration files containing lists of available service addresses, and distributing these configuration files to all the clients in the network. Administrators must also define client preferences, such as trace level, encryption, and security service integration. These are also contained in configuration files that must be distributed to all the clients in the network.

ADDING CLIENTS

Administrators frequently need to add additional clients to the network. Each client, in turn, needs to access the latest configuration information if it is going to successfully connect with all the services available. One way that administrators try to ensure all clients are installed with the latest configuration files is to define a standard network location to store these files, and then distribute this location to all of the parties involved in installing and configuring clients. Even if this procedure is followed rigorously, however, it is still unlikely that all clients will end up with current configuration information.

ADDING SERVICES

It is another frequent network management task to add new services to an existing network. The system administrator must generate and distribute new configuration files to all clients in the network that will use this new service, as well as to other servers that will establish inter-database links to this service. Since new services may be deployed frequently and the total number of platforms involved could easily number in the thousands, keeping all of these configuration files up to date is a challenge.

RELOCATING SERVICES

Another issue is that applications are frequently relocated to different platforms. For example, as the user base for an application grows, it may become necessary to host that application on a larger server platform. In some cases it may be practical to swap out the machine at the current network address. More likely, however, because other applications or users are hosted on that machine, it will be necessary to change the network address, operating system or even networking protocol of the service. This means, once again, that a new set of configuration files will have to be distributed to all the clients and servers which need to connect to that service.

CHANGING CLIENT PROFILES

Client profiles are a set of client-specific connection preferences, they are composed of configuration information that controls the operation and features used by Net8 clients and servers when establishing connections and communicating with each other. These are stored as a set of parameters in a configuration file that specifies such client preferences as trace level, encryption, and security service integration. There are more and more instances where administrators may want to alter these profiles for a certain class of user with the growing usage of Internet-based business application software such as CRM. For example, they may want to enable data encryption for a group of remote users accessing sensitive financial information. In a typical environment, this involves using a tool such as Net8 Assistant to generate new client profiles, and then distributing the resulting configuration files to the various clients impacted.

Such a model is very limited because a client on a remote node cannot share a SQLNET.ORA file, a configuration file containing client or server's name, address and connect information, on a local node, so the file needs to be replicated on multiple nodes and individually configured. Also, the multiple copies of SQLNET.ORA on every system makes management of the files a nightmare for system administrators who must manage them locally on every machine.

Given the magnitude of the administrative overhead generated by frequent network changes, there is clearly a need for a better way of managing and controlling access to configuration information for the various clients and services in the network.

THE SOLUTIONS: NET8 LDAP DIRECTORY NAMING AND CONFIGURATIONS

Starting from Oracle8i release 2, Oracle's network services functionality, Net8, addresses these challenges, supplies the industry's most comprehensive, enterprise-wide data access solution for complex computing environments. Net8 enables Oracle databases to seamlessly communicate in client-server and server-server configurations through Internet, allowing databases and applications to reside on different computers. Please refer to the figure below:

LDAP DIRECTORY NAMING

In addition to a variety of existing naming solutions designed to give customers a high degree of flexibility in how they integrate Oracle services into their dynamic environments, Net8 provides another naming solution, LDAP directory naming, to address today's dynamic, complex, enterprise-wide network management.

Net8's support for LDAP-compliant directory services via Oracle Internet Directory provides a centralized vehicle for managing and configuring a distributed, heterogeneous network. The network directory becomes the central repository for all information on databases, network components, and user and corporate policies and preferences, replacing client-side and server-side localized files. Administrators can centrally manage these objects and all systems on the heterogeneous network can refer to the directory for information. Please refer to the figure below:

PROFILE MANAGEMENT AND REMOTE CONFIGURATION - NET8'S FUTURE FEATURES

With Net8's support of LDAP directory services, the SQLNET.ORA file can be eliminated from individual sites and instead be stored in Oracle Internet Directory. Net8 user profiles may also be stored in Oracle Internet Directory to facilitate Web access and remote administration. Net8 will also allow profiles to be shared across multiple systems and users.

Oracle's network profiles can be one of the following: a) machine-specific, b) application-specific and c) service- or group-specific. In addition to network profiles, an application can choose to retain a local profile (actually the same old SQLNET.ORA ) that will be stored locally on its machine.

The current model for Net8 configuration requires the existence of configuration files such as LISTENER.ORA, INIT.ORA, CMAN.ORA in each system that Net8 is installed. Thus, when a new database system is configured, the database information needs to be updated in each of the client site that will need to access the new database. Oracle's support of directory services, on the other hand, will enable remote configuration and easier maintenance. An administrator will therefore be able to configure a remote listener or install a service/instance on a remote node.

Net Manager in Oracle9i has implemented LDAP-compliant directory naming solutions to address the need for central naming management. With the prevalence of Internet computing, there is now a need for a single tool to provide a complete set of functionality for the management of the entire Oracle network and its components. This functionality will eventually be included into Oracle's Net Manager. By leveraging Oracle Internet Directory's LDAP-compliant directory services, the Net Manager will provide both configuration and management for the entire network, including network service name, listeners, profiles, and connection manager.

NET8 LDAP DIRECTORY NAMING

Directory naming is the process of resolving an alias using an LDAP-compliant directory service (specifically, Oracle Internet Directory). Net8 directory naming allows net service names to be stored in and retrieved from Oracle Internet Directory. Net service names stored in OID are accessible by any client machine in the network as long as the client has sufficient access privileges. An explanation of directory naming working procedure is shown as below:

A client initiates a connect request providing a connect identifier (e.g., sales.us.oracle.com).
1. The connect identifier is used to retrieve a connect descriptor (e.g., port number, host name, protocol, instance, …) stored in Oracle Internet Directory, which is sent back to the client.
2. The client makes the connect request to the address provided in the connect descriptor.
3. A listener receives the request and directs it to the server.

The centralization of network names and addresses in Oracle Internet Directory facilitates administration of changes and updates, by eliminating the need for an administrator to make changes to what potentially could be hundreds of thousands of clients. Centralized administration also makes network changes invisible to users and client applications on several different levels - examples of this include location transparency and containment transparency.

LOCATION TRANSPARENCY

Using Net8's centralized administration lets administrators hide the details of a service's network location from client applications. All the client needs to know is the network-wide name assigned to the service. Net8 takes care of resolving this service name into a service address at connect time.

CONTAINMENT TRANSPARENCY

Containment transparency refers to how easily server resources can be moved without requiring changes to client applications. With Net8's centralized administration, services can be relocated from one server platform to another with a minimum of disruption and downtime for administration. A change may only need to be made once in Oracle Internet Directory to reflect the new location of the service. No changes to client configuration files or applications are necessary. This makes "right-sizing" of applications easier by allowing administrators to stage services on the correct platform.

In Oracle9i, Net8 provides Net8 Manager and Net8 Configuration Assistant, two easy-to-use graphical tools, for configuration and management of the entire network and its components. Several new features in Net8 improve Net8 LDAP support significantly and make Oracle9i the most LDAP-oriented database today. These new features are summarized as below:

• Improvements in Net8 Manager and Net8 Configuration Assistant ease LDAP-compliant directory configuration and management considerably. Net8 Configuration Assistant allows administrators to create multiple Oracle Context directory entries within Oracle Internet Directory, for storing Oracle databases and net service names across administrative boundary lines.
  
• Net8 Manager allows administrators to change the default naming context so that all the information under different naming contexts can be viewed and edited. This facilitates management of complex, hierarchical naming structures.
  

• Oracle Names Proxy enables customers to migrate seamlessly from Oracle Names to Oracle Internet Directory for naming purposes. The proxy allows Oracle Names client machines to continuously connect to Oracle Names server, which acts as a proxy for loading data from Oracle Internet Directory. Thus, only one system needs to be maintained during the migration period. This feature is especially useful to some customers with large number of Oracle Names client machines deployed, because it is almost impossible to convert tens of thousands of client machines into LDAP simultaneously.
  
  Page 2