8 Configuring High Availability for Identity Management Components

The Oracle Identity Management products enable you to configure and manage the identities of users, devices, and services across diverse servers, to delegate administration of these identities, and to provide end users with self-service privileges. You use these products to configure single sign-on across applications and to process users' credentials to ensure that only users with valid credentials can log into and access online resources.

It is critical to configure high availability for the Oracle Identity Management products because other enterprise-level applications depend on them. If the Oracle Identity Management products fail, applications depending on them also fail.

This chapter describes configuring the 11g Release 1 Identity Management products for high availability in an active-active configuration. These products include:

Note:

For Oracle Identity and Access Management components that are new or updated for 11g Release 2 (11.1.2), see Chapter 9, "Configuring High Availability for Identity and Access Management Components."

This chapter includes the following topics:

8.1 Identity Management Product Components and High Availability Concepts

Figure 8-1 shows a sample Oracle Identity Management high availability architecture.

Figure 8-1 Oracle Identity Management High Availability Architecture

Description of Figure 8-1 follows
Description of "Figure 8-1 Oracle Identity Management High Availability Architecture"

In Figure 8-1, the web tier includes the WEBHOST1 and WEBHOST2 computers.

An Oracle HTTP Server instance is installed on WEBHOST1 and an Oracle HTTP Server instance is installed on WEBHOST2. A load balancing router routes requests to the Oracle HTTP Server instances on WEBHOST1 and WEBHOST2.

The application tier includes the IDMHOST1 and IDMHOST2 computers.

On IDMHOST1, the following installations have been performed:

  • An Oracle Directory Services Manager instance and an Oracle Directory Integration Platform instance have been installed in the WLS_ODS1 Managed Server. The Oracle RAC database has been configured in a JDBC multi data source to protect the instances from Oracle RAC node failure.

  • An Oracle Access Manager Access Server instance has been installed in the WLS_OAM1 Managed Server.

  • A WebLogic Administration Server has been installed. Under normal operations, this is the active Administration Server. The Administration Server is a singleton application. The Oracle Access Manager Console has also been installed as a singleton application.

On IDMHOST2, the following installations have been performed:

  • An Oracle Directory Services Manager instance and an Oracle Directory Integration Platform instance have been installed in the WLS_ODS2 Managed Server. The Oracle RAC database has been configured in a JDBC multi data source to protect the instances from Oracle RAC node failure.

    The instances in the WLS_ODS2 Managed Server on IDMHOST2 and the instances in the WLS_ODS1 Managed Server on IDMHOST1 are configured as the Cluster_ODS cluster.

  • An Oracle Access Manager Access Server instance has been installed in the WLS_OAM2 Managed Server.

    The Access Server instance in the WLS_OAM2 Managed Server on IDMHOST2 and the Access Server instance in the WLS_OAM1 Managed Server on IDMHOST1 are configured as the Cluster_OAM cluster.

  • A WebLogic Administration Server has been installed. Under normal operations, this is the passive Administration Server. You will make this Administration Server active if the Administration Server on IDMHOST1 becomes unavailable. See Chapter 12, "Active-Passive Topologies for Oracle Fusion Middleware High Availability" for more information about active-passive configurations. The Oracle Access Manager Console has also been installed as a singleton application, and it is passive until the Administration Server on IDMHOST2 becomes active.

The directory tier includes the OIDHOST1 and OIDHOST2 computers.

On OIDHOST1, an Oracle Internet Directory instance and an Oracle Virtual Directory instance have been installed. Transparent Application Failover (TAF) connects the Oracle Internet Directory instance with the Oracle RAC database that serves as the security metadata repository. The database is enabled for server-side TAF and HA Events Notification.

OIDHOST2 has an identical setup.

The Oracle Internet Directory instances on OIDHOST1 and OIDHOST2 are configured as a cluster.

An Oracle Real Applications Cluster (Oracle RAC) database serves as the security metadata repository.

8.2 Prerequisites for Oracle Identity Management High Availability Configuration

This section describes steps that you must complete before setting up an Oracle Identity Management high availability configuration.

8.2.1 Oracle Home Requirement

The Oracle home for the Identity Management components must be the same across all nodes. For example, if you choose /u01/app/oracle/product/fmw/idm as the Oracle home on Node1, then you must choose /u01/app/oracle/product/fmw/idm as the Oracle home on all subsequent nodes.

8.2.2 Database Prerequisites

Several Oracle Identity Management components require a supported database and schemas.

To check if your database is certified or to see all certified databases, see the "Certified Databases" section in the Certification Document:

http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html

To determine the database version, run this query:

SQL>select version from sys.product_component_version where product like 'Oracle%';

8.2.3 Installing and Configuring the Database Repository

Oracle recommends a highly available database to store the metadata repository. For maximum availability, Oracle recommends using an Oracle Real Application Clusters (Oracle RAC) database. Oracle also recommends that the database use Oracle Automatic Storage Management for data storage. If you use Oracle ASM, the best practice is to also use Oracle Managed Files.

If you use Oracle ASM, install it into its own Oracle Home and have two disk groups:

  • One for the Database files.

  • One for the Flash Recovery Area.

This section provides links to instructions for installing and configuring a database repository.

Oracle Clusterware

  • For 10g Release 2 (10.2), see Oracle Database Oracle Clusterware and Oracle Real Application Clusters Installation Guide.

  • For 11g Release 1 (11.1) and later, see Oracle Clusterware Installation Guide.

Automatic Storage Management and Oracle Real Application clusters

When you run the installer, select Configure Automatic Storage Management in the Select Configuration page to create a separate Automatic Storage Management home.

Many Oracle Fusion Middleware components require schemas in a database prior to installation. See the next section for information on using RCU to load the Oracle Identity Management schemas into an Oracle RAC database repository.

8.2.4 Obtaining the Repository Creation Utility Software

To obtain the latest version of RCU, go to the Oracle Fusion Middleware 11g Software Download page on Oracle Technology Network:

http://www.oracle.com/technology/software/products/middleware/htdocs/fmw_11_download.html

Look for Repository Creation Utility in the Required Additional Software table. After downloading the .zip file, extract the contents to a directory of your choice; this directory is referred to as the RCU_HOME directory.

Before you install any components this chapter describes, run RCU to create the schemas into an Oracle RAC database. High availability Oracle Identity Management configurations require these schemas.

For additional information about RCU, see Oracle Fusion Middleware Installation Planning Guide for Oracle Identity and Access Management and Oracle Fusion Middleware Repository Creation Utility User's Guide.

8.2.5 Configuring the Database for Oracle Fusion Middleware 11g Metadata

Create the Oracle Real Application Clusters database to store Oracle Fusion Middleware 11g metadata with the following characteristics:

  • It should be in archive log mode to facilitate backup and recovery.

  • Optionally, flashback should be enabled.

  • It should be created with the ALT32UTF8 character set.

The value of the static PROCESSES initialization parameter must be 500 or greater for Oracle Internet Directory. The Repository Creation Utility checks this value.

To check the value, use the SHOW PARAMETER command in SQL*Plus:

prompt> sqlplus "sys/password as sysdba"
SQL> SHOW PARAMETER processes

One common method of changing the parameter value is to use a command similar to the following and then stop and restart the database to make the parameter take effect:

prompt> sqlplus "sys/password as sysdba"
SQL> ALTER SYSTEM SET PROCESSES=500 SCOPE=SPFILE;

The method that you use to change a parameter's value depends on whether the parameter is static or dynamic, and on whether your database uses a parameter file or a server parameter file. See the Oracle Database Administrator's Guide for details on parameter files, server parameter files, and how to change parameter values.

8.2.5.1 Database Examples in This Chapter

Table 8-1 shows values used for database configuration examples in this chapter.

Table 8-1 Databases Used in Identity Management Configuration Examples

Component Database Service Name Database Instance Name

Oracle Internet Directory

oid.example.com

oiddb1, oiddb2

Oracle Virtual Directory

N/A

N/A

Oracle Directory Integration Platform

oid.example.com

oiddb1, oiddb2

Oracle Directory Services Manager

N/A

N/A

Oracle Identity Navigator

N/A

N/A

Oracle Identity Federation

oif.example.com

oifdb1, oifdb2

Oracle Identity Management

idm.example.com

idmdb1,idmdb2

8.2.5.2 Database Services

Oracle recommends using the Oracle Enterprise Manager Cluster Managed Services Page to create database services that client applications will use to connect to the database. For complete instructions on creating database services, see the chapter on Workload Management in the Oracle Real Application Clusters Administration and Deployment Guide.

To use SQL*Plus to configure your Oracle RAC database to automate failover for Oracle Internet Directory, use the following instructions. Note that each of the following commands only has to be run on one node in the cluster:

  1. Use the CREATE_SERVICE subprogram to both create the database service and enable high availability notification and configure server-side Transparent Application Failover (TAF) settings:

    prompt> sqlplus "sys/password as sysdba"

SQL> EXECUTE DBMS_SERVICE.CREATE_SERVICE
(SERVICE_NAME => 'idm.example.com',
NETWORK_NAME => 'idm.example.com',
AQ_HA_NOTIFICATIONS => TRUE, 
FAILOVER_METHOD => DBMS_SERVICE.FAILOVER_METHOD_BASIC, 
FAILOVER_TYPE => DBMS_SERVICE.FAILOVER_TYPE_SELECT, 
FAILOVER_RETRIES => 5, FAILOVER_DELAY => 5);

    You must enter the EXECUTE DBMS_SERVICE command on a single line to run it properly.

  2. Add the service to the database and assign it to the instances using srvctl:

    prompt> srvctl add service -d idmdb -s idm -r idmdb1,idmdb2

  3. Start the service using srvctl:

    prompt> srvctl start service -d idmdb -s  idm

    Note:

    For more information about the SRVCTL command, see the Oracle Real Application Clusters Administration and Deployment Guide.

If you already have a service in the database, ensure that it is enabled for high availability notifications and configured with the proper server-side Transparent Application Failover (TAF) settings. Use the DBMS_SERVICE package to modify the service to enable high availability notification to be sent through Advanced Queuing (AQ) by setting the AQ_HA_NOTIFICATIONS attribute to TRUE and configure server-side TAF settings, as shown below:

prompt> sqlplus "sys/password as sysdba"

SQL> EXECUTE DBMS_SERVICE.MODIFY_SERVICE
(SERVICE_NAME => 'idm.example.com',
AQ_HA_NOTIFICATIONS => TRUE,
FAILOVER_METHOD => DBMS_SERVICE.FAILOVER_METHOD_BASIC, 
FAILOVER_TYPE => DBMS_SERVICE.FAILOVER_TYPE_SELECT, 
FAILOVER_RETRIES => 5, FAILOVER_DELAY => 5);

You must enter the EXECUTE DBMS_SERVICE command on a single line for it to run properly.

Note:

For more information about the DBMS_SERVICE package, see the Oracle Database PL/SQL Packages and Types Reference.

When using a 11.2 database, follow the steps in the "Creating and Deleting Database Services with SRVCTL" section of the Oracle Database Administrator's Guide for 11g Release 2 (11.2).

8.2.5.3 Verifying Transparent Application Failover (TAF)

This section describes how to validate the Transparent Application Failover (TAF) configuration settings made earlier.

After the Oracle Internet Directory process starts, you can query the FAILOVER_TYPE, FAILOVER_METHOD, and FAILED_OVER columns in the V$SESSION_VIEW to obtain information about connected clients and their TAF status.

For example, use the following SQL statement to verify that TAF is correctly configured:

SELECT MACHINE, FAILOVER_TYPE, FAILOVER_METHOD, FAILED_OVER, COUNT(*)
FROM V$SESSION
GROUP BY MACHINE, FAILOVER_TYPE, FAILOVER_METHOD, FAILED_OVER;

The output before failover is similar to this:

MACHINE              FAILOVER_TYPE FAILOVER_M  FAI   COUNT(*)
-------------------- ------------- ---------- ---- ----------
oidhost1             SELECT        BASIC       NO          11
oidhost1             SELECT        BASIC       NO           1

The output after failover is similar to this:

MACHINE              FAILOVER_TYPE FAILOVER_M  FAI   COUNT(*)
-------------------- ------------- ---------- ---- ----------
oidhost2             SELECT        BASIC       NO          11
oidhost2             SELECT        BASIC       NO           1

8.2.5.4 Configuring Virtual Server Names and Ports for the Load Balancer

This section describes the network prerequisites for deploying an Oracle Identity Management high availability environment.

8.2.5.4.1 Load Balancers

All components in the Oracle Identity Management software stack require a hardware load balancer when deployed in a high availability configuration. Oracle recommends that the hardware load balancer have these features:

  • Ability to load-balance traffic to a pool of real servers through a virtual hostname:

    Clients access services using the virtual hostname (instead of using actual host names). The load balancer can then load balance requests to the servers in the pool.

  • Port translation configuration: Port translation enables incoming requests received on one port to be routed to a server process running on a different port. For example, a request received on port 80 can be routed to port 7777.

  • Protocol translation: The load balancer should support protocol translation between systems running different protocols. It enables users on one network to access hosts on another network, despite differences in the native protocol stacks associated with the originating device and the targeted host. For example, incoming requests can be HTTPS, and outgoing requests can be HTTP.

  • SSL acceleration: SSL acceleration is a method of offloading the processor-intensive public key encryption algorithms involved in SSL transactions to a hardware accelerator.

  • Monitoring of ports (HTTP, HTTPS, LDAP, LDAPS)

  • Virtual servers and port configuration

    Ability to configure virtual server names and ports on your external load balancer, and the virtual server names and ports must meet the following requirements:

    • The load balancer should enable configuration of multiple virtual servers. For each virtual server, the load balancer should enable configuration of traffic management on more than one port. For example, for Oracle Internet Directory clusters, the load balancer needs to be configured with a virtual server and ports for LDAP and LDAPS traffic.

    • The virtual server names must be associated with IP addresses and be part of your DNS. Clients must be able to access the load balancer through the virtual server names.

  • Ability to detect node failures and immediately stop routing traffic to the failed node

  • Resource monitoring / port monitoring / process failure detection

    The load balancer must be able to detect service and node failures (through notification or some other means) and to stop directing non-Oracle Net traffic to the failed node. If your load balancer has the ability to automatically detect failures, you should use it.

  • Fault-tolerant mode

    It is highly recommended that you configure the load balancer to be in fault-tolerant mode.

  • Other

    Oracle recommends that you configure the load balancer virtual server to return immediately to the calling client when the back-end services that it forwards traffic to are unavailable. This is preferred over the client disconnecting on its own after a timeout based on the TCP/IP settings on the client machine.

  • Sticky routing capability

    Ability to maintain sticky connections to components based on cookies or URL.

Table 8-2 shows the virtual server names to use for the external load balancer in the Oracle Identity Management high availability environment.

Table 8-2 Virtual Server Names for the External Load Balancer

Component Virtual Server Name

Oracle Internet Directory

oid.example.com

Oracle Virtual Directory

ovd.example.com

Oracle Identity Federation

oif.example.com

Oracle Directory Services Manager Console

admin.example.com

8.2.5.4.2 Virtual Server Names

This section describes the virtual server names that Oracle recommends you set up for the high availability deployments that this chapter describes.

Ensure that the virtual server names are associated with IP addresses and are part of your Domain Name System (DNS). The computers on which Oracle Fusion Middleware is running must be able to resolve these virtual server names

oid.example.com

This virtual server acts as the access point for all LDAP traffic to the Oracle Internet Directory servers in the directory tier. Traffic to both the SSL and non-SSL ports is configured. The clients access this service using the address oid.example.com:636 for SSL and oid.example.com:389 for non-SSL.

Monitor the heartbeat of the Oracle Internet Directory processes on OIDHOST1 and OIDHOST2. If an Oracle Internet Directory process stops on OIDHOST1 or OIDHOST2, or if either host OIDHOST1 or OIDHOST2 is down, the load balancer must continue to route the LDAP traffic to the surviving computer.

ovd.example.com

This virtual server acts as the access point for all LDAP traffic to the Oracle Virtual Directory servers in the directory tier. Traffic to both the SSL and non-SSL port is configured. The clients access this service using the address ovd.example.com:7501 for SSL and ovd.example.com:6501 for non-SSL.

Monitor the heartbeat of the Oracle Virtual Directory processes on OVDHOST1 and OVDHOST2. If an Oracle Virtual Directory process stops on OVDHOST1 or OVDHOST2, or if either host OVDHOST1 or OVDHOST2 is down, the load balancer must continue to route the LDAP traffic to the surviving computer.

oif.example.com

This virtual server acts as the access point for all HTTP traffic to the Oracle Identity Federation servers in the application tier.

8.3 Oracle Internet Directory High Availability

This section provides an introduction to Oracle Internet Directory and describes how to design and deploy a high availability environment for Oracle Internet Directory.

This section includes the following topics:

8.3.1 Oracle Internet Directory Component Architecture

Oracle Internet Directory is an LDAP store that can be used by Oracle components such as Directory Integration Platform, Oracle Directory Services Manager, JPS, and also by non-Oracle components. These components connect to Oracle Internet Directory using the LDAP or LDAPS protocols.

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/Oracle Net Services. Oracle Directory Services Manager and the command-line tools communicate with the Oracle directory servers over LDAP.

Figure 8-2 shows Oracle Internet Directory in a high availability architecture.

Figure 8-2 Oracle Internet Directory in a High Availability Architecture

Description of Figure 8-2 follows
Description of "Figure 8-2 Oracle Internet Directory in a High Availability Architecture"

An Oracle Internet Directory node consists of one or more directory server instances connected to the same directory store. The directory store—that is, the repository of the directory data—is an Oracle database.

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

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

  • The Oracle directory server non-SSL port (389 for this topology)

  • The Oracle directory server SSL-enabled port (636 for this topology)

  • The OID Monitor

LDAP is used for connections between the directory server and:

  • Oracle Directory Services Manager

  • Oracle directory replication server

The Oracle directory server instance and the Oracle directory replication server connect to OID Monitor by way of the operating system. See Section 8.3.4, "Configuring a Maximum High Availability Oracle Internet Directory Deployment (Multimaster Replication)" for more information on Oracle Internet Directory replication.

Figure 8-2 shows Oracle Internet Directory node major elements:

Table 8-3 An Oracle Internet Directory Node

Element Description

Oracle directory server instance

Also called either an LDAP server instance or a directory server instance, it services directory requests through a single Oracle Internet Directory dispatcher process listening at specific TCP/IP ports. There can be more than one directory server instance on a node, listening on different ports.

Oracle directory replication server

Also called a replication server, it tracks and sends changes to replication servers in another Oracle Internet Directory system. There can be only one replication server on a node. You can choose whether to configure the replication server. If there are multiple instances of Oracle Internet Directory that use the same database, only one of them can be running replication. This is true even if the Oracle Internet Directory instances are on different nodes.

The replication sever process is a process within Oracle Internet Directory. It only runs when replication is configured.

For more information about Oracle Internet Directory replication, see Section 8.3.4, "Configuring a Maximum High Availability Oracle Internet Directory Deployment (Multimaster Replication)."

Oracle Database Server

Stores the directory data. Oracle strongly recommends that you dedicate a database for use by the directory. The database can reside on the same node as the directory server instances.

Oracle Process Manager and Notification Server (OPMN)

Manages Oracle Internet Directory as an Oracle Fusion Middleware component. OPMN uses the directives in the Oracle Internet Directory component snippet in ORACLE_INSTANCE/opmn.xml and invokes OIDMON and OIDCTL as required. The command-line utility is opmnctl.

OID Monitor (OIDMON)

Initiates, monitors, and terminates the LDAP server and replication server processes. When you invoke process management commands, such as oidctl or opmnctl, or when you use Fusion Middleware Control to start or stop server instances, your commands are interpreted by this process.

OIDMON also monitors servers and restarts them if they have stopped running for abnormal reasons.

OIDMON starts a default instance of OIDLDAPD. If the default instance of OIDLDAPD is stopped using the OIDCTL command, then OIDMON stops the instance. When OIDMON is restarted by OPMN, OIDMON restarts the default instance.

All OID Monitor activity is logged in the file ORACLE_INSTANCE/diagnostics/log/OID/component_id/oidmon-xxxx.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. Normally used from the command line only to stop and start the replication server.

8.3.1.1 Oracle Internet Directory Component Characteristics

Oracle Internet Directory, which is Oracle's LDAP store, is a C-based component that uses a database as its persistence store. It is a stateless process and stores all of the data and the majority of its configuration information in the back-end database. It uses Oracle Net Services to connect to the database.

This section includes the following topics:

See the topic "Oracle Internet Directory Replication Server Control and Failover" in the Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory for information about process control and failover for the Oracle Internet Directory replication server (oidrepld) in a Maximum Availability Architecture.

8.3.1.1.1 Runtime Processes

Oracle Internet Directory has the following runtime processes:

  • OIDLDAPD: This is the main process for Oracle Internet Directory. OIDLDAPD consists of a dispatcher process and a server process. The dispatcher process spawns the OIDLDAPD server processes during startup. Each OIDLDAPD dispatcher process has its own SSL and non-SSL ports for receiving requests. Every instance has one dispatcher and one server process by default. The number of server processes spawned for an instance is controlled by the orclserverprocs attribute.

  • OIDMON: OIDMON is responsible for the process control of an Oracle Internet Directory instance. This process starts, stops, and monitors Oracle Internet Directory. During startup OIDMON spawns the OIDLDAPD dispatcher process and the replication server process, if replication is configured for the instance.

  • Replication server process: This is a process within Oracle Internet Directory that runs only when replication is configured. The replication server process is spawned by OIDMON during startup.

  • OPMN: The Oracle Process Manager and Notification Server (OPMN) is a daemon process that monitors Oracle Fusion Middleware components, including Oracle Internet Directory. Oracle Enterprise Manager Fusion Middleware Control uses OPMN to stop or start instances of Oracle Internet Directory. If you stop or start Oracle Internet Directory components from the command line, you use opmnctl, the command-line interface to OPMN.

    OPMN is responsible for the direct start, stop, restart and monitoring of OIDMON. It does not start or stop the server process directly.

8.3.1.1.2 Process Lifecycle

OPMN is responsible for the direct start, stop, restart and monitoring of the daemon process, OIDMON (ORACLE_HOME/bin/oidmon). OIDMON is responsible for the process control of an Oracle Internet Directory instance. In 11g Release 2 (11.1.2), you can have multiple instances of Oracle Internet Directory on the same Oracle instance on the same node. For details, refer to Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory.

Process Status Table

Oracle Internet Directory process information is maintained in the ODS_PROCESS_STATUS table in the ODS database user schema. OIDMON reads the contents of the table at a specified interval and acts upon the intent conveyed by the contents of that table. The interval is controlled by the value of the sleep command line argument used at OIDMON startup, and the default value is 10 seconds.

Starting and Stopping Oracle Internet Directory

An Oracle Internet Directory instance can be started and stopped using the Oracle Enterprise Manager Fusion Middleware Control or the command opmnctl.

Start Process

The start process for Oracle Internet Directory is:

  1. Upon receiving the start command, OPMN issues an oidmon start command with appropriate arguments, as specified in the opmn.xml file.

  2. OIDMON then starts all Oracle Internet Directory Server instances whose information in the ODS_PROCESS_STATUS table has state value 1 or 4 and ORACLE_INSTANCE, COMPONENT_NAME, INSTANCE_NAME values matching the environment parameters set by OPMN.

Stop Process

The stop process for Oracle Internet Directory is:

  1. Upon receiving the stop command, OPMN issues an oidmon stop command.

  2. For each row in the ODS_PROCESS_STATUS table that matches the environment parameters ORACLE_INSTANCE, COMPONENT_NAME, and INSTANCE_NAME, the oidmon stop command kills OIDMON, OIDLDAPD, and OIDREPLD processes and updates the state to 4.

Monitoring

OPMN does not monitor server processes directly. OPMN monitors OIDMON and OIDMON monitors the server processes. The events are:

  • When you start OIDMON through OPMN, OPMN starts OIDMON and ensures that OIDMON is up and running.

  • If OIDMON goes down for some reason, OPMN brings it back up.

  • OIDMON monitors the status of the Oracle Internet Directory dispatcher process, LDAP server processes, and replication server process and makes this status available to OPMN and Oracle Enterprise Manager Fusion Middleware Control.

8.3.1.1.3 Request Flow

Once the Oracle Internet Directory process starts up, clients access Oracle Internet Directory using the LDAP or LDAPS protocol. There is no impact on other running instances when an Oracle Internet Directory instance starts up.

Oracle Internet Directory listener/dispatcher starts a configured number of server processes at startup time. The number of server processes is controlled by the orclserverprocs attribute in the instance-specific configuration entry. The default value for orclserverprocs is 1. Multiple server processes enable Oracle Internet Directory to take advantage of multiple processor systems.

The Oracle Internet Directory dispatcher process sends the LDAP connections to the Oracle Internet Directory server process in a round robin fashion. The maximum number of LDAP connections accepted by each server is 1024 by default. This number can be increased by changing the attribute orclmaxldapconns in the instance-specific configuration entry, which has a DN of the form:

cn=componentname,cn=osdldapd,cn=subconfigsubentry

Database connections from each server process are spawned at server startup time, depending on the value set for the instance configuration parameters ORCLMAXCC and ORCLPLUGINWORKERS. The number of database connections spawned by each server equals ORCLMAXCC + ORCLPLUGINWORKERS + 2. The Oracle Internet Directory server processes communicate with the Oracle database server through Oracle Net Services. An Oracle Net Services listener/dispatcher relays the request to the Oracle database. For more information, refer to Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory.

8.3.1.1.4 Configuration Artifacts

The storage location requires a DB connect string. TNSNAMES.ORA is stored in ORACLE_INSTANCE/config. The wallet is stored in ORACLE_INSTANCE/OID/admin (The DB ODS user password is stored in the wallet).

8.3.1.1.5 External Dependencies

Oracle Internet Directory uses an Oracle database to store configuration information as well as data. It uses the ODS schema to store this information.

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/Oracle Net Services. Oracle Directory Services Manager and the command-line tools communicate with the Oracle directory servers over LDAP.

8.3.1.1.6 Oracle Internet Directory Log File

Log files for Oracle Internet Directory are under the following directory:

ORACLE_INSTANCE/diagnostics/log/OID

Table 8-4 shows Oracle Internet Directory processes and the log file name and location for the process.

Table 8-4 Locations of Oracle Internet Directory Process Log Files

Process Log File Location

Directory server (oidldapd)

ORACLE_INSTANCE/diagnostics/logs/ OID/componentName/oidldapd00sPID-XXXX.log where:

00 is the instance number (00 by default)

s stands for server

PID is the server process identifier

XXXX is a number from 0000 to orclmaxlogfilesconfigured. Once the orclmaxlogfilesconfigured value is reached, it starts over again from 0000. When it starts over, it truncates the file to 0 bytes.

ORACLE_INSTANCE/diagnostics/logs/OID/componentName/oidstackInstNumberPID.log

LDAP dispatcher (oidldapd)

ORACLE_INSTANCE/diagnostics/logs/ OID/componentName/oidldapd00-XXXX.log where:

00 is the instance number (00 by default)

XXXX is a number from 0000 to orclmaxlogfilesconfigured

OID Monitor (OIDMON)

ORACLE_INSTANCE/diagnostics/logs/ OID/componentName/oidmon-XXXX.log where:

XXXX is a number from 0000 to orclmaxlogfilesconfigured

Directory replication server (oidrepld)

ORACLE_INSTANCE/diagnostics/logs/OID/ componentName/oidrepld-XXXX.log where:

XXXX is a number from 0000 to orclmaxlogfilesconfigured

For more information on using the log files to troubleshoot Oracle Internet Directory issues, see Section 8.3.7, "Troubleshooting Oracle Internet Directory High Availability".

8.3.2 Oracle Internet Directory High Availability Concepts

This section provides conceptual information about using Oracle Internet Directory in a high availability two-node Cluster Configuration. See Section 8.3.2.3, "Oracle Internet Directory Prerequisites" for prerequisites and Section 8.3.3, "Oracle Internet Directory High Availability Configuration Steps" for specific steps for setting up the two-node Cluster Configuration.

8.3.2.1 Oracle Internet Directory High Availability Architecture

Figure 8-3 shows the Oracle Internet Directory Cluster Configuration high availability architecture in an active-active configuration.

Figure 8-3 Oracle Internet Directory Cluster Configuration High Availability Architecture

Description of Figure 8-3 follows
Description of "Figure 8-3 Oracle Internet Directory Cluster Configuration High Availability Architecture"

Figure 8-3 shows Oracle Internet Directory in the directory tier in a Cluster Configuration high availability architecture. Clustering is set up at installation time. The load balancing router routes LDAP client requests to the two Oracle Internet Directory instances that are clustered on OIDHOST1 and OIDHOST2.

Transparent Application Failover (TAF) connects the Oracle Internet Directory instances with the Oracle RAC database that serves as the security metadata repository. The Oracle RAC database is configured in TNSNAMES.ORA. High availability event notification is used for notification when an Oracle RAC instance becomes unavailable. See Section 4.1.7.1, "Oracle Internet Directory" for more information about using Oracle Internet Directory with Oracle RAC.

8.3.2.1.1 Starting and Stopping the Cluster

In the Cluster Configuration, OPMN commands start each Oracle Internet Directory instance. There is no impact to Oracle Internet Directory at startup. A new database connection is spawned when Oracle Internet Directory starts.

When the cluster is stopped using OPMN, Oracle Internet Directory disconnects from the database and the Oracle Internet Directory server stops.

8.3.2.1.2 Cluster-Wide Configuration Changes

Configuration changes can be done at a cluster level to any instance in the Cluster Configuration. All nodes in the Cluster Configuration that share the same database read the same configuration information. The OIDMON process polls for configuration changes on each Oracle Internet Directory server and updates the database repository about configuration changes. OIDMON and other Oracle Internet Directory servers pull the changes from the database repository. In this way, any change made at a cluster member level is propagated to every Oracle Internet Directory server in the cluster.

The instance-specific configuration attributes for an Oracle Internet Directory LDAP server configuration are stored in this LDAP entry:

cn=<component-name>,cn=configsets,cn=osdldapd,cn=subconfigsubentry

Oracle Internet Directory server configuration aspects such as the number of servers, database connections, sizelimit, and timelimit are part of the instance-specific server configuration entry.

The configuration attributes that are common to all Oracle Internet Directory instances in a cluster are stored in the LDAP entry:

cn=dsaconfig,cn=configsets,cn=osdldapd,cn=oracle internet directory

If you want to retain instance-specific server configuration attributes for each Oracle Internet Directory instance in the cluster, then you should choose a distinct Oracle Internet Directory component name for each Oracle Internet Directory instance at install/configuration time; for example, oid1 on node1 and oid2 on node2. In this case, the configuration entries will be cn=oid1,cn=osdldapd,cn=subconfigsubentry and cn=oid2,cn=osdldapd,cn=subconfigsubentry respectively and they need to be updated separately for each Oracle Internet Directory instance.

However, if you choose to have a common set of server configuration attributes for both Oracle Internet Directory instances in the cluster, then you should choose the same Oracle Internet Directory component name for both Oracle Internet Directory instances, for example, oid1 on both Oracle Internet Directory node1 and node2. In this case, there will be one common configuration entry cn=oid1,cn=osdldapd,cn=subconfigsubentry.

Oracle Internet Directory LDAP server instances cache certain LDAP metadata artifacts such as Schema, ACLs, and Password Policy. Multiple Oracle Internet Directory LDAP server processes on a given node keep their caches in sync via semantics built around a shared memory segment managed by Oracle Internet Directory on each node. OIDMON keeps these caches in sync across nodes by ensuring that these shared memory segments are in sync across the nodes, which is achieved using the Oracle Internet Directory database.

Oracle Internet Directory also caches metadata and metadata changes trigger notification across the nodes. The ldapmodify utility is used to change metadata. The Oracle Internet Directory server that gets the ldapmodify request for the metadata change notifies other Oracle Internet Directory servers about the change of metadata (including OIDMON). OIDMON is responsible for notifying OIDMON on other nodes about the metadata changes.

8.3.2.2 Protection from Failures and Expected Behavior

This section discusses protection from different types of failure in an Oracle Internet Directory Cluster Configuration.

8.3.2.2.1 Oracle Internet Directory Process Failure

OIDMON monitors Oracle Internet Directory processes. If the Oracle Internet Directory process goes down, OIDMON tries to restart it.

OPMN monitors OIDMON. If OIDMON goes down, OPMN restarts OIDMON.

If an Oracle Internet Directory process cannot be restarted, then the front-ending load balancing router detects failure of Oracle Internet Directory instances in the Cluster Configuration and routes LDAP traffic to surviving instances. In case of failure, the LDAP client retries the transaction. If the instance fails in the middle of a transaction, the transaction is not committed to the database. When the failed instance comes up again, the load balancing router detects this and routes requests to all the instances.

If an Oracle Internet Directory instance in the Cluster Configuration gets hung, the load balancing router detects this and routes requests to surviving instances.

If one of the Oracle Internet Directory instances in the two-node Cluster Configuration fails (or if one of the computers hosting an instance fails), the load balancing router routes clients to the surviving Oracle Internet Directory instance.

8.3.2.2.2 Expected Client Application Behavior When Failure Occurs

Oracle Internet Directory server failure is usually transparent to Oracle Internet Directory clients as they continue to get routed through the load balancer. External load balancers are typically configured to perform a health check of Oracle Internet Directory processes. If a request is received before the load balancer detects process unavailability, clients application could receive a error. If the client application performs a retry, the load balancer should route it to a healthy Oracle Internet Directory instance and the request should be successful.

In Oracle Internet Directory active-active configurations, if you are doing ldapadd operations through the LDIF file at the time of failover, your operation would fail even if you are doing this operation through a load balancer host and port. This is because Oracle Internet Directory is down for a fraction of a second. For most applications, this will not be an issue because most applications have the ability to retry the connection a fixed number of times.

8.3.2.2.3 External Dependency Failure

This section describes the protection available for Oracle Internet Directory from database failure.

By default, the tnsnames.ora file configured in Oracle Internet Directory's ORACLE_INSTANCE ensures that Oracle Internet Directory's connections to the database are load balanced between the Oracle RAC database instances. For example, if an Oracle Internet Directory instance establishes four database connections, two connections are made to each database instance.

Oracle Internet Directory uses database high availability event notification to detect database node failure and to fail over to a surviving node.

If Transparent Application Failover (TAF) is configured, then upon a database instance failure, Oracle Internet Directory will fail over its database connections to the surviving database instance, which enables the LDAP search operations that were in progress during the failover to be continued.

If both Transparent Application Failover (TAF) and high availability event notification are configured, Transparent Application Failover (TAF) is used for failover and high availability event notifications are used only for logging the events. The high availability event notifications are logged in OIDLDAPD log file.

Oracle Internet Directory also has a mechanism to detect stale database connections, which enables Oracle Internet Directory to reconnect to the database.

If none of the database instances are available for a prolonged period, then the Oracle Internet Directory LDAP and REPL processes will automatically be shut down. However, OIDMON and OPMN will continue to ping for the database instance availability and when the database becomes available, the Oracle Internet Directory processes (LDAP and REPL) are automatically restarted by OIDMON.

While all the database instances are down, OIDMON continue to be up and an opmnctl status command shows that OIDLDAPD instances are down. When a database instance becomes available, OIDMON restarts all configured Oracle Internet Directory instances.

All database failover induced activity for Oracle Internet Directory is recorded in the OIDMON log file.

8.3.2.3 Oracle Internet Directory Prerequisites

This section describes prerequisites for setting up the Oracle Internet Directory high availability architecture.

8.3.2.3.1 Synchronizing the Time on Oracle Internet Directory Nodes

Before setting up Oracle Internet Directory in a high availability environment, you must ensure that the time on the individual Oracle Internet Directory nodes is synchronized.

Synchronize the time on all nodes using Greenwich Mean Time so that there is a discrepancy of no more than 250 seconds between them.

If OID Monitor detects a time discrepancy of more than 250 seconds between the two nodes, the OID Monitor on the node that is behind stops all servers on its node. To correct this problem, synchronize the time on the node that is behind in time. The OID Monitor automatically detects the change in the system time and starts the Oracle Internet Directory servers on its node.

If there are more than two nodes, the same behavior is followed. For example, assume that there are three nodes, where the first node is 150 seconds ahead of the second node, and the second node is 150 seconds ahead of the third node. In this case, the third node is 300 seconds behind the first node, so the OID Monitor will not start the servers on the third node until the time is synchronized.

8.3.2.3.2 Using RCU to Create Oracle Internet Directory Schemas in the Repository

Before you can install the Oracle Internet Directory instances on OIDHOST1 and OIDHOST2, you must use the latest version of the Repository Creation Utility (RCU) to create the collection of schemas used by Oracle Identity Management and Management Services.

See Oracle Fusion Middleware Repository Creation Utility User's Guide for more information about obtaining and running the latest version of RCU.

Follow these steps to run RCU and create the Identity Management schemas in an Oracle RAC database repository:

  1. Issue this command:

    prompt> RCU_HOME/bin/rcu &

  2. On the Welcome screen, click Next.

  3. On the Create Repository screen, select the Create operation to load component schemas into an existing database.

    Click Next.

  4. On the Database Connection Details screen, enter connection information for the existing database as follows:

    Database Type: Oracle Database

    Host Name: Name of the computer on which the database is running. For an Oracle RAC database, specify the VIP name or one node name. Example: INFRADBHOST1-VIP or INFRADBHOST2-VIP

    Port: The port number for the database. Example: 1521

    Service Name: The service name of the database. Example: oid.example.com

    Username: SYS

    Password: The SYS user password

    Role: SYSDBA

    Click Next.

  5. On the Select Components screen, create a new prefix and select the components to be associated with this deployment:

    Create a New Prefix: idm (Entering a prefix is optional if you select only Identity Management (Oracle Internet Directory - ODS) in the Components field)

    Components: Select Identity Management (Oracle Internet Directory - ODS). De-select all other schemas.

    Click Next.

  6. On the Schema Passwords screen, enter the passwords for the main and additional (auxiliary) schema users.

    Click Next.

  7. On the Map Tablespaces screen, select the tablespaces for the components.

  8. On the Summary screen, click Create.

  9. On the Completion Summary screen, click Close.

8.3.2.3.3 Load Balancer Virtual Server Names for Oracle Internet Directory

When Oracle Internet Directory is deployed in a high availability configuration, it is recommended to use an external load balancer to front-end the Oracle Internet Directory instances and load balance requests between the various Oracle Internet Directory instances.

Refer to Section 8.2.5.4, "Configuring Virtual Server Names and Ports for the Load Balancer" for details.

8.3.3 Oracle Internet Directory High Availability Configuration Steps

You can deploy Oracle Internet Directory in a highly availability configuration either in a standalone mode or as a part of a WebLogic Server domain.

Oracle recommends standalone mode for deployments where you manage Oracle Internet Directory using command line tools, and where Oracle Enterprise Manager Fusion Middleware Control and Oracle Directory Services Manager are not deemed mandatory. Later, you can register standalone Oracle Internet Directory instances with a remote WebLogic Server domain using opmnctl commands. Oracle Enterprise Manager Fusion Middleware Control and Oracle Directory Services Manager can be used to manage Oracle Internet Directory instances that are configured with an WebLogic Server domain.

Oracle recommends that you set up Oracle Internet Directory in a clustered deployment, where the clustered Oracle Internet Directory instances access the same Oracle RAC database repository.

This section includes the following topics:

8.3.3.1 Installing Oracle Fusion Middleware Components

This section describes how to install the required binaries for the WebLogic Server (WL_HOME) and Oracle Home for (ORACLE_HOME) for Oracle Identity Management.

Oracle strongly recommends that you read the release notes for any additional installation and deployment considerations prior to starting the setup process.

This section includes the following topics:

8.3.3.1.1 Install Oracle WebLogic Server

The first step in the installation procedure is to install WebLogic Server.

See "Understanding Your Installation Starting Point" in Oracle Fusion Middleware Installation Planning Guide for Oracle Identity and Access Management for the version of WebLogic Server to use with the latest version of Oracle Fusion Middleware.

Ensure that the system, patch, kernel and other requirements are met. These are listed in the Oracle Fusion Middleware Installation Guide for Oracle WebLogic Server.

Start the Oracle WebLogic Server installer.

Then follow these steps in the installer to install WebLogic Server on the computer:

  1. On the Welcome screen, click Next.

  2. On the Choose Middleware Home Directory screen, select Create a New Middleware Home. Then choose a directory on your computer into which the Oracle WebLogic software is to be installed.

    For the Middleware Home Directory, specify this value:

    /u01/app/oracle/product/fmw

    Click Next.

  3. On the Register for Security Updates screen, enter your "My Oracle Support" User Name and Password so that you can be notified of security updates

  4. On the Choose Install Type screen, the installation program prompts you to indicate whether you wish to perform a complete or a custom installation.

    Choose Custom.

    Click Next.

  5. On the Choose Products and Components screen, select only Oracle JRockit SDK and click Next.

  6. On the Choose Product Installation Directories screen, accept the directory /u01/app/oracle/fmw/wlserver_10.3.

    Click Next.

  7. On the Installation Summary screen, the window contains a list of the components you selected for installation, along with the approximate amount of disk space to be used by the selected components once installation is complete.

    Click Next.

  8. On the Installation Complete screen, deselect the Run Quickstart checkbox.

    Click Done.

8.3.3.1.2 Installing Oracle Fusion Middleware for Identity Management

The next step is to install the Oracle Fusion Middleware components.

Note:

Because the installation is performed on shared storage, the two MW_HOME installations are accessible and used by the remaining servers in the topology.

Ensure that the system, patch, kernel and other requirements are met. These are listed in the Oracle Fusion Middleware Installation Guide for Oracle Identity Management in the Oracle Fusion Middleware documentation library for the version you are using.

If the /etc/oraInst.loc file exists, verify that its contents are correct. Specifically, check that the inventory directory is correct and that you have write permissions for that directory. If the /etc/oraInst.loc file does not exist, you can skip this step.

Start the installer for Oracle Fusion Middleware components:

HOST1> ./runInstaller

Before starting the install, ensure that the following environment variables are not set:

  • LD_ASSUME_KERNEL

  • ORACLE_INSTANCE

On the Specify Inventory Directory screen, do the following:

  • Enter HOME/oraInventory, where HOME is the home directory of the user performing the installation (this is the recommended location).

  • Enter the OS group for the user performing the installation. Click Next.

For a UNIX install, follow the instructions on screen to run createCentralInventory.sh as root.

Click OK.

Proceed as follows:

  1. On the Specify Oracle Inventory Directory screen, enter HOME/oraInventory, where HOME is the home directory of the user performing the installation (This is the recommended location).

    Enter the OS group for the user performing the installation.

    Click Next.

  2. On the Welcome screen, click Next.

  3. On the Select Installation Type screen, select Install-Do Not Configure.

    Click Next.

  4. On the Prerequisite Checks screen, verify that the checks complete successfully, then click Next.

  5. On the Specify Installation Location screen, enter the following values:

    MW_HOME: Enter the value of the MW_HOME, for example:

    /u01/app/product/fmw

    Select the previously installed Middleware Home from the drop-down list. For the Oracle Home directory, enter the directory name IDM.

    Click Next.

  6. On the Summary screen, click Install.

    When prompted, run the script oracleRoot.sh as the root user.

  7. On the Installation Complete screen, click Finish.

8.3.3.1.3 Upgrading Oracle Identity Management

This section provides the steps to upgrade your Oracle Identity Management software. For more information, see Applying the Latest Oracle Fusion Middleware Patch Set in the Oracle Fusion Middleware Patching Guide.

  1. Start the IDM Upgrade Installer by running ./runinstaller.

  2. On the Welcome screen, click Next.

  3. On the Prerequisite Checks screen, click Next.

  4. On the Specify Install Location screen, provide the path to the Oracle Middleware Home and the name of the Oracle Home directory.

  5. On the Installation Summary screen, validate your selections, and then click Install.

  6. The Installation Progress screen shows the progress of the install.

    Once the installation is done, the oracleRoot.sh confirmation dialog box appears. This dialog box advises you that a configuration script needs to be run as root before the installation can proceed. Leaving the confirmation dialog box open, open another shell window, log in as root, and run this script file: /u01/app/oracle/product/fmw/id/oracleRoot.sh. After the script completes, click OK on the Confirmation Dialog box.

  7. On the Installation Complete screen, click Finish to exit.

8.3.3.2 Configuring Oracle Internet Directory Without a WebLogic Domain

This section describes the steps to deploy Oracle Internet Directory without a WebLogic Server domain.

This section includes the following topics:

8.3.3.2.1 Configuring Oracle Internet Directory on OIDHOST1

Ensure that the schema database is running and that RCU has been used to seed the ODS database schema, then follow these steps to configure the Oracle Internet Directory instance on OIDHOST1:

  1. Ensure that the system, patch, kernel and other requirements are met. These are listed in the Oracle Fusion Middleware Installation Guide for Oracle Identity Management in the Oracle Fusion Middleware documentation library for the version you are using.

  2. Ensure that Oracle Identity Management software has been installed and upgraded on OIDHOST1 as described in Section 8.3.3.1, "Installing Oracle Fusion Middleware Components."

  3. Ensure that the load balancer is configured as About Virtual Server Names Used by the Topologies in the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management describes.

  4. Ensure that ports 389 and 636 are not in use by any service on the computer by issuing these commands for the operating system you are using. If a port is not in use, no output is returned from the command.

    netstat -an | grep LISTEN | grep ":389" 

netstat -an | grep LISTEN | grep ":636"

  5. If the port is in use (if the command returns output identifying the port), you must free the port.

    Remove the entries for ports 389 and 636 in the /etc/services file and restart the services, or restart the computer.

  6. Start the Oracle Identity Management 11g Configuration Wizard under the ORACLE_HOME/bin directory as follows:

    ./config.sh

  7. On the Welcome screen, click Next.

  8. On the Select Domain screen, select Configure without a Domain and then click Next.

  9. On the Specify Installation Location screen, specify the following values:

    • Oracle Middleware Home Location: This value is prefilled and cannot be changed.

    • Oracle Home Directory:

      /u01/app/oracle/product/fmw/idm

    • Oracle Instance Location:

      /u01/app/oracle/admin/oid_instance1

    • Oracle Instance Name:

      oid_instance1

      Note:

      Ensure that the Oracle Home Location directory path for OIDHOST1 is the same as the Oracle Home Location path for OIDHOST2. For example, if the Oracle Home Location directory path for OIDHOST1 is:

      /u01/app/oracle/product/fmw/idm

      then the Oracle Home Location directory path for OIDHOST2 must be:

      /u01/app/oracle/product/fmw/idm

    Click Next.

  10. On the Specify Email for Security Updates screen, specify these values:

    • Email Address: Provide the email address for your My Oracle Support account.

    • Oracle Support Password: Provide the password for your My Oracle Support account.

    • Check the checkbox next to the I wish to receive security updates via My Oracle Support field.

    Click Next.

  11. On the Configure Components screen, select Oracle Internet Directory, deselect all the other components, and click Next.

  12. On the Configure Ports screen, select Specify Ports Using Configuration File and enter the filename for the staticports.ini file that you copied to the temporary directory.

    Click Next.

  13. On the Specify Schema Database screen, select Use Existing Schema and specify the following values:

    • Connect String:

      infradbhost1-vip.example.com:1521:oiddb1^infradbhost2-vip.example.com:1521:oiddb2@oid.example.com

      Note:

      The Oracle RAC database connect string information needs to be provided in the format host1:port1:instance1^host2:port2:instance2@servicename.

      During this installation, it is not required for all the Oracle RAC instances to be up. If one Oracle RAC instance is up, the installation can proceed.

      It is required that the information provided above is complete and accurate. Specifically, the correct host, port, and instance name must be provided for each Oracle RAC instance, and the service name provided must be configured for all the specified Oracle RAC instances.

      Any incorrect information entered in the Oracle RAC database connect string has to be corrected manually after the installation.

    • User Name: ODS

    • Password: ******

    Click Next.

  14. On the Create Oracle Internet Directory screen, specify the Realm and enter the Administrator (cn=orcladmin) password and click Next.

  15. On the Installation Summary screen, review the selections to ensure that they are correct (if they are not, click Back to modify selections on previous screens) and click Install.

  16. On the Installation Progress screen, a dialog box appears that prompts you to run the oracleRoot.sh script. Open a window and run the script, following the prompts in the window.

    Click Next.

  17. On the Configuration screen, multiple configuration assistants are launched in succession; this process can be lengthy. When it completes, click Next.

  18. On the Installation Complete screen, click Finish to confirm your choice to exit.

8.3.3.2.2 Oracle Internet Directory Component Names Assigned by Oracle Identity Management Installer

When you perform an Oracle Internet Directory installation using Oracle Identity Management 11g installer, the default component name that the installer assigns to the Oracle Internet Directory instance is oid1. You cannot change this component name.

The instance-specific configuration entry for this Oracle Internet Directory instance is cn=oid1, cn=osdldapd, cn=subconfigsubentry.

If you perform a second Oracle Internet Directory installation on another computer and that Oracle Internet Directory instance uses the same database as the first instance, the installer detects the previously installed Oracle Internet Directory instance on the other computer using the same Oracle database, so it gives the second Oracle Internet Directory instance a component name of oid2.

The instance-specific configuration entry for the second Oracle Internet Directory instance is cn=oid2, cn=osdldapd, cn=subconfigsubentry. Any change of properties in the entry cn=oid2, cn=osdldapd, cn=subconfigsubentry will not affect the first instance (oid1).

If a third Oracle Internet Directory installation is performed on another computer and that instance uses the same database as the first two instances, the installer gives the third Oracle Internet Directory instance a component name of oid3, and so on for additional instances on different hosts that use the same database.

Note that the shared configuration for all Oracle Internet Directory instances is cn=dsaconfig, cn=configsets,cn=oracle internet directory. Any change in this entry will affect all the instances of Oracle Internet Directory.

This naming scheme helps alleviate confusion when you view your domain using Oracle Enterprise Manager by giving different component names to your Oracle Internet Directory instances.

8.3.3.2.3 Configuring Oracle Internet Directory on Additional Hosts (Scaling Out)

Ensure that the Oracle Internet Directory repository is running and then follow these steps to configure the Oracle Internet Directory instance on an additional host. This procedure uses the host OIDHOST2.

Note:

The instructions in this section can also be used to scale out Oracle Internet Directory in your 11g Oracle Identity Management high availability configuration.

  1. Ensure that the system, patch, kernel and other requirements are met. These are listed in the Oracle Fusion Middleware Installation Guide for Oracle Identity Management in the Oracle Fusion Middleware documentation library.

  2. Ensure that Oracle Identity Management software has been installed and upgraded on OIDHOST2 as described in Section 8.3.3.1, "Installing Oracle Fusion Middleware Components."

  3. On OIDHOST1, ports 389 and 636 were used for Oracle Internet Directory. The same ports should be used for the Oracle Internet Directory instance on OIDHOST2. Therefore, ensure that ports 389 and 636 are not in use by any service on OIDHOST2 by issuing these commands for the operating system you are using. If a port is not in use, no output is returned from the command.

    netstat -an | grep LISTEN | grep ":389" 

netstat -an | grep LISTEN | grep ":636"

  4. If the port is in use (if the command returns output identifying the port), you must free the port.

    Remove the entries for ports 389 and 636 in the /etc/services file and restart the services, or restart the computer.

  5. Copy the staticports.ini file from the Disk1/stage/Response directory to a temporary directory.

  6. Edit the staticports.ini file you copied to the temporary directory to assign the following custom ports (uncomment the lines where you specify the port numbers for Oracle Internet Directory):

    # The Non-SSL port for OID
Oracle Internet Directory Port No = 389
# The SSL port for OID
Oracle Internet Directory (SSL) Port No = 636

  7. Start the Configuration Wizard under the ORACLE_HOME/bin directory as follows:

    ./config.sh

  8. On the Welcome screen, click Next.

  9. On the Select Domain screen, select Configure without a Domain and then click Next.

  10. On the Specify Installation Location screen, specify the following values:

    • Oracle Middleware Home Location: This value is prefilled and cannot be changed.

    • Oracle Home Directory:

      /u01/app/oracle/product/fmw/idm

    • Oracle Instance Location:

      /u01/app/oracle/admin/oid_instance2

    • Oracle Instance Name:

      oid_instance2

      Note:

      Ensure that the Oracle Home Location directory path for OIDHOST2 is the same as the Oracle Home Location directory path for OIDHOST1. For example, if the Oracle Home Location directory path for OIDHOST1 is:

      /u01/app/oracle/product/fmw/idm

      then the Oracle Home Location directory path for OIDHOST2 must be:

      /u01/app/oracle/product/fmw/idm

    Click Next.

  11. On the Specify Email for Security Updates screen, specify these values:

    • Email Address: Provide the email address for your My Oracle Support account.

    • Oracle Support Password: Provide the password for your My Oracle Support account.

    • Check the checkbox next to the I wish to receive security updates via My Oracle Support field.

    Click Next.

  12. On the Configure Components screen, select Oracle Internet Directory, deselect all the other components, and click Next.

  13. On the Configure Ports screen, select Specify Ports Using Configuration File and enter the filename for the staticports.ini file that you copied to the temporary directory.

    Click Next.

  14. On the Specify Schema Database screen, select Use Existing Schema and specify the following values.

    • Connect String:

      infradbhost1-vip.example.com:1521:oiddb1^infradbhost2-vip.example.com:1521:oiddb2@oid.example.com

      Note:

      The Oracle RAC database connect string information needs to be provided in the format host1:port1:instance1^host2:port2:instance2@servicename.

      During this installation, it is not required for all the Oracle RAC instances to be up. If one Oracle RAC instance is up, the installation can proceed.

      It is required that the information provided above is complete and accurate. Specifically, the correct host, port, and instance name must be provided for each Oracle RAC instance, and the service name provided must be configured for all the specified Oracle RAC instances.

      Any incorrect information entered in the Oracle RAC database connect string has to be corrected manually after the installation.

    • User Name: ODS

    • Password: ******

    Click Next.

  15. The ODS Schema in use message appears. The ODS schema chosen is already being used by the existing Oracle Internet Directory instance. Therefore, the new Oracle Internet Directory instance being configured would reuse the same schema.

    Choose Yes to continue.

  16. On the Specify OID Administrator Password screen, specify the OID Administrator password and click Next.

  17. On the Installation Summary screen, review the selections to ensure that they are correct (if they are not, click Back to modify selections on previous screens), and click Install.

  18. On the Installation Progress screen on UNIX systems, a dialog box appears that prompts you to run the oracleRoot.sh script. Open a window and run the script, following the prompts in the window.

    Click Next.

  19. On the Configuration screen, multiple configuration assistants are launched in succession; this process can be lengthy. When it completes, click Next.

  20. On the Installation Complete screen, click Finish to confirm your choice to exit.

8.3.3.2.4 Registering Oracle Internet Directory with a WebLogic Domain

To manage an Oracle Internet Directory component with Oracle Enterprise Manager Fusion Middleware Control, you must register the component and the Oracle Fusion Middleware instance that contains it with an WebLogic Server domain. You can register an Oracle Fusion Middleware instance with a WebLogic domain during installation or Oracle instance creation, but you are not required to do so. If an Oracle Fusion Middleware instance is not registered with a domain, register it using the command opmnctl registerinstance.

Before using the opmnctl registerinstance command to register an instance with a WebLogic Server domain, ensure that the WebLogic Server is installed.

Then run the opmnctl registerinstance command in this format (note that the ORACLE_HOME and ORACLE_INSTANCE variables have to be set for each installation before running this command in the home directory for the Oracle Virtual Directory instance):

opmnctl registerinstance -adminHost WLSHostName -adminPort WLSPort
-adminUsername adminUserName

For example:

opmnctl registerinstance -adminHost oidhost1.example.com -adminPort 7001
-adminUsername weblogic

Command requires login to weblogic admin server (oidhost1.example.com)
 Username: weblogic
 Password: *******

For additional details on registering components with a WebLogic domain, see the "Registering an Oracle Instance Using OPMNCTL" section in Oracle Fusion Middleware Administrator's Guide for Oracle Virtual Directory.

8.3.4 Configuring a Maximum High Availability Oracle Internet Directory Deployment (Multimaster Replication)

This section provides high-level instructions for setting up a maximum high availability deployment for Oracle Internet Directory with multimaster replication. Multimaster replication replicates data from the master site to the replica site. Oracle recommends that you use LDAP multimaster replication for the maximum availability Oracle Internet Directory deployment.

Figure 8-4 shows the maximum high availability deployment for Oracle Internet Directory.

Figure 8-4 Maximum High Availability Multimaster Replication Deployment

Description of Figure 8-4 follows
Description of "Figure 8-4 Maximum High Availability Multimaster Replication Deployment"

The master site is located in New York and the replica site is located in Los Angeles.

Each site includes a highly available two-node Oracle Internet Directory cluster configuration that uses an Oracle RAC database as a highly available security store. Each two-node cluster has a load balancer. See Section 8.3.3, "Oracle Internet Directory High Availability Configuration Steps" to set up a two-node Oracle Internet Directory cluster.

The master site in New York consists of:

  • OIDHOST1 and OIDHOST2

    These are the two clustered hosts on which Oracle Internet Directory is installed.

  • RAC_DB1

    The Oracle RAC database which serves as the security store for the Oracle Internet Directory instances on OIDHOST1 and OIDHOST2. Multimaster replication replicates data between RAC_DB1 in New York and RAC_DB2 in Los Angeles.

The replica site in Los Angeles consists of:

  • OIDHOST3 and OIDHOST4

    These are the two clustered hosts on which Oracle Internet Directory is installed.

  • RAC_DB2

    This is the Oracle RAC database which serves as the security store for the Oracle Internet Directory instances on OIDHOST3 and OIDHOST4. Multimaster replication replicates data between RAC_DB1 in New York and RAC_DB2 in Los Angeles.

This section includes the following topics:

8.3.4.1 Replication Types

The following types of replication are available for Oracle Internet Directory:

  • LDAP multimaster replication

    Uses the industry-standard Lightweight Directory Access Protocol Version 3 as the replication transport mechanism. Oracle recommends this protocol for replication.

  • Oracle Advanced Database multimaster replication

    Uses the replication feature of Oracle Database, also called Advanced Replication.

  • Two-way fan-out replication

    With this replication method, the replicated data is read/write at both the master site and replica site. Fan-out uses LDAP as its transport mechanism.

  • One-way fan-out replication

    With this replication method, the replicated data is read-only at the replica site. Fan-out uses LDAP as its transport mechanism.

For more information about the replication types for Oracle Internet Directory, see Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory.

For the maximum availability deployment shown in Figure 8-4, either LDAP or Oracle Advanced Database multimaster replication can be set up.

8.3.4.2 Setting up Multimaster Replication

This section describes how to set up LDAP multimaster replication or Oracle Advanced Database multimaster replication for the maximum high availability Oracle Internet Directory deployment shown in Figure 8-4.

Note:

See Section 8.3.3, "Oracle Internet Directory High Availability Configuration Steps" for information on installing the Oracle Internet Directory two-node clusters for the New York and Los Angeles multimaster topology shown in Figure 8-4.

Note:

For new Oracle Fusion Middleware 11g customers who want to install and configure 10.1.4.3 or later Oracle Single Sign-On and Oracle Delegated Administration Services against 11g Oracle Internet Directory and to set up multimaster replication, see these steps:

  1. To configure 10.1.4.3 Oracle Single Sign-On and Oracle Delegated Administration Services to run against 11g Oracle Internet Directory, see the "Special Instructions for Oracle Single Sign-On and Oracle Delegated Administration Services Users" section of Oracle Fusion Middleware Installation Guide for Oracle Identity Management.

  2. Perform the steps in the following sections of the "Deploying Identity Management with Multimaster Replication" chapter in the Oracle Fusion Middleware High Availability Guide for release 10.1.4.0.1 (part number B28186-01) to install and configure 10.1.4.3 Oracle Single Sign-On and Oracle Delegated Administration Services for multimaster replication:

    • Section 10.1.4 "Installing OracleAS Single Sign-On and Oracle Delegated Administration Services on the Master Node"

    • Section 10.1.5 "Synchronizing the OracleAS Single Sign-On Schema Password"

    • Section 10.1.6 "Installing OracleAS Single Sign-On and Oracle Delegated Administration Services on the Replica Node"

    • Section 10.1.7 "If You Are Running in SSL Mode"

8.3.4.2.1 Setting Up LDAP Multimaster Replication

Follow these steps in Oracle Enterprise Manager Fusion Middleware Control to set up LDAP multimaster replication:

  1. From the Oracle Internet Directory menu on the Oracle Internet Directory instance home page, choose Administration, and then Replication Management.

  2. You are prompted to log into the replication DN account. Provide the host, port of one of the Oracle Internet Directory servers at the master site (the New York cluster in Figure 8-4), replication DN, and replication DN password. If anonymous binds are enabled on this Oracle Internet Directory component, the replication DN field will fill in automatically when you enter the host and port.

  3. Click Create.

  4. On the Type screen, select the replication type: Multimaster Replication.

  5. Click Next. The Replicas screen shows the replication type you selected.

  6. Provide an agreement name that is unique across all nodes.

  7. For multimaster replication, enter the host, port, user name (replication DN), and replication password for the primary node and all the secondary nodes.

    Note:

    Enter the host/port of any of the Oracle Internet Directory instances in the cluster.

  8. Click Next to go the Settings page.

  9. In the LDAP Connection field, select Keep Alive if you want the replication server to use same connection for performing multiple LDAP operations. Select Always Use New Connection if you want the server to open a new connection for each LDAP operation.

  10. Enter the Replication Frequency.

  11. Enter the Human Intervention Queue Schedule. This is the interval, in minutes, at which the directory replication server repeats the change application process.

  12. The Replication Server Start Details section has options to start the replication server and enable bootstrap. Choose Start Server to start the appropriate server instance. You can also enable bootstrap by choosing Enable Bootstrap. You must select the Instance Name and Component Name from the drop-down lists to start the server.

  13. Click Next to go to the Scope page. The default primary naming context will be filled in. Keep the default settings.

  14. Click Next. The Summary page shows a summary of the replication agreement you are about to create. To make any changes to information on the Summary page, click Back.

  15. Click Finish to create the replication agreement.

For detailed instructions on setting up LDAP multimaster replication, read the Oracle Enterprise Manager tool tips or refer to Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory.

8.3.4.2.2 Adding a Node in LDAP Multimaster Replication

Follow these steps in the Oracle Enterprise Manager Fusion Middleware Control to add a node in an LDAP multimaster replication deployment:

  1. From the Oracle Internet Directory menu on the Oracle Internet Directory instance home page, select Administration then Replication Management.

  2. At the prompt to log into the replication DN account, enter the host, port and replication DN password of any of the replicas in the multimaster replication deployment.

  3. In the upper half of the screen, click on the appropriate multimaster replication agreement row to enable editing.

  4. Click Edit on the Replication Agreements page.

  5. In the lower half of the screen, click the Replicas tab.

  6. To add a new replica to the multimaster replication deployment, click Create.

  7. Enter the host, port and replication DN password details for the new node. Click Add.

  8. Click Apply. The replica is added to the existing multimaster directory replication group (DRG).

For more information, see Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory.

8.3.4.2.3 Deleting a Node in LDAP Multimaster Replication

Follow these steps in the Oracle Enterprise Manager Fusion Middleware Control to delete a node in an LDAP multimaster replication deployment:

  1. From the Oracle Internet Directory menu on the Oracle Internet Directory instance home page, select Administration, and then Replication Management.

  2. You will be prompted to log into the replication DN account. Provide the host, port and replication DN password of any of the replicas in the multimaster replication deployment.

  3. In the upper half of the screen, click on the appropriate multimaster replication agreement row to enable editing.

  4. Click Edit on Replication Agreement screen.

  5. In the lower half of the screen, click the Replicas tab.

  6. Click the replica you want to delete from the multimaster replication deployment.

  7. Click Delete.

  8. Click the Apply button to remove the replica from the LDAP multimaster directory replication group (DRG).

For more detailed information on deleting a node in an LDAP multimaster replication deployment, see Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory.

8.3.4.2.4 Setting Up Oracle Advanced Database Multimaster Replication

The detailed steps for setting up Oracle Advanced Database multimaster replication are available in the "Installing and Setting Up an Oracle Database Advanced Replication-Based Multimaster Replication Group" section in Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory.

Table 8-5 shows the subsections of the "Installing and Setting Up an Oracle Database Advanced Replication-Based Multimaster Replication Group" section in Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory. It also describes the instructions to perform in each subsection to set up Oracle Advanced Database multimaster replication for the maximum high availability Oracle Internet Directory deployment shown in Figure 8-4.

Table 8-5 Steps for Setting Up Oracle Database Advanced Multimaster Replication

Subsection Instructions

Task 1: Install Oracle Internet Directory on the Master Definition Site (MDS)

This task should already have been performed based on the Note in Section 8.3.4.2, "Setting up Multimaster Replication."

Task 2: Install the Oracle Internet Directory on the Remote Master Sites (RMS)

This task should already have been performed based on the Note in Section 8.3.4.2, "Setting up Multimaster Replication."

If an Existing Master is Used as a Remote Master Site

Set up one site as the master definition site (MDS), for example, the New York site. Then set up one Oracle Internet Directory node in the cluster at the master site (for example, OIDHOST1) to be the master host. OIDHOST1 will be the host in the master site cluster where the replication server will be configured and will run. When the setup steps require a reference to a replication server, process, or port for the MDS, specify the correct value for OIDHOST1.

Set up another site as the remote master site (RMS), for example, the Los Angeles site. Then set up one Oracle Internet Directory node in the cluster at the remote site (for example, OIDHOST3) to be the replica host. The replica host is referred to as the "new node" in the "If an Existing Master is Used as a Remote Master Site" section). OIDHOST3 will be the host in the Los Angeles cluster where the replication server will be configured and will run. When the setup steps require a reference to a replication server, process, or port for the RMS, specify the correct value for OIDHOST3.

Task 3: Set Up Advanced Replication for a Directory Replication Group

Follow the instructions for this task.

On All Nodes, Prepare the Oracle Net Services Environment for Replication

Perform the steps in this subsection in all the database Oracle homes and in all the Oracle Internet Directory Oracle homes in the New York site and the Los Angeles site.

From the MDS, Configure Advanced Replication For Directory Replication

Perform the steps in this subsection in all of the Oracle Internet Directory Oracle homes in New York and Los Angeles, with one exception:

When you configure Advanced Replication using the Replication Environment Management Tool, run the command on only the master host at the MDS site (for example, on OIDHOST1 in New York). The replication must be started on only one Oracle Internet Directory host.

Task 4 (Optional): Load Data into the Directory

If you choose to use the bulkload utility, stop all the Oracle Internet Directory instances in all the Oracle Internet Directory homes, and use only one of the Oracle Internet Directory instances to perform the bulkload operation.

Task 5: Ensure that Oracle Directory Server Instances are Started on All the Nodes

Perform this task in all the Oracle Internet Directory Oracle home directories.

Task 6: Start the Replication Servers on All Nodes in the DRG

Start the replication server on only OIDHOST1 in New York and OIDHOST3 in Los Angeles.

8.3.4.2.5 Adding a Node in Oracle Advanced Database Multimaster Replication

The detailed steps for adding a node in an Oracle Advanced Database multimaster replication deployment are in the "Adding a Node for Oracle Database Advanced Replication-Based Multimaster Replication Group" section in Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory.

Table 8-6 shows the subsections of the "Adding a Node for Oracle Database Advanced Replication-Based Multimaster Replication Group" section in Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory. It also describes the instructions to perform in each subsection to add a node to the maximum high availability Oracle Internet Directory deployment shown in Figure 8-4.

Table 8-6 Steps for Adding a Node in Oracle Advanced Database Replication

Subsection Instructions

Prepare the Oracle Net Services Environment

Perform the steps in this subsection in all the database Oracle homes and in all the Oracle Internet Directory Oracle homes in the master definition site (New York site) and the remote master definition site (Los Angeles site).

Also, perform these steps in the database Oracle homes and in all the Oracle Internet Directory Oracle homes for the new cluster that is being added.

Task 1: Stop the Directory Replication Server on All Nodes

Stop the replication server on OIDHOST1 in New York and on OIDHOST3 in Los Angeles.

Task 2: Identify a Sponsor Node and Install Oracle Internet Directory on the Remote Site

OIDHOST1 in the New York cluster will be the sponsor node and the MDS.

Task 3: Switch the Sponsor Node to Read-Only Mode

Perform this task in the Oracle home for Oracle Internet Directory on OIDHOST1 and OIDHOST2.

Task 4: Back up the Sponsor Node by Using ldifwrite

Perform this task in the Oracle home for Oracle Internet Directory on OIDHOST1.

Task 5: Perform Advanced Replication Add Node Setup

Perform this task in the Oracle home for Oracle Internet Directory on OIDHOST1.

Task 6: Switch the Sponsor Node to Updatable Mode

Perform this task in the Oracle home for Oracle Internet Directory on OIDHOST1 and OIDHOST2.

Task 7: Start the Directory Replication Server on All Nodes Except the New Node

Perform this task on OIDHOST1 in the New York cluster and on OIDHOST3 in the Los Angeles cluster.

Task 8: Load Data into the New Node by Using bulkload

Perform this task on one of the Oracle Internet Directory Oracle homes in the new cluster that is being added.

Stop all the Oracle Internet Directory processes on the new node before using bulkload.

Task 9: Start the Directory Server on the New Node

Perform this task on all of the Oracle Internet Directory nodes in the new cluster that is being added.

Task 10: Start the Directory Replication Server on the New Node

Perform this task on one of the Oracle Internet Directory Oracle homes in the new cluster that is being added.

8.3.4.2.6 Deleting a Node in Oracle Advanced Database Multimaster Replication

The detailed steps for deleting a node in an Oracle Advanced Database multimaster replication deployment are in the "Deleting a Node from a Multimaster Replication Group" section in Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory.

Table 8-7 shows the subsections of the "Deleting a Node from a Multimaster Replication Group" section in Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory. It also describes the instructions to perform in each subsection to delete a node in the maximum high availability Oracle Internet Directory deployment shown in Figure 8-4. In the instructions, the MDS is assumed to be the New York site.

Table 8-7 Steps for Deleting a Node in Oracle Advanced Database Replication

Subsection Instructions

Task 1: Stop the Directory Replication Server on All Nodes

Perform this task on each node in the Directory Replication Group (DRG).

Task 2: Stop All Oracle Internet Directory Processes in the Node to be Deleted

Perform this task in the node to be deleted.

Task 3: Delete the Node from the Master Definition Site

Perform this task in the Oracle home for Oracle Internet Directory on OIDHOST1.

Task 4: Start the Directory Replication Server on All Nodes

Perform this task on all the remaining nodes in the DRG.

8.3.5 Validating Oracle Internet Directory High Availability

Use the ldapbind command-line tool to ensure that you can connect to each Oracle Internet Directory instance and the LDAP Virtual Server. The ldapbind tool enables you to determine whether you can authenticate a client to a server.

Note:

See the "Configuring Your Environment" section of Oracle Fusion Middleware Reference for Oracle Identity Management for a list of the environment variables you must set before using the ldapbind command.

For non-SSL:

ldapbind -h oidhost1.example.com -p 389 -D "cn=orcladmin" -q
ldapbind -h oidhost2.example.com -p 389 -D "cn=orcladmin" -q
ldapbind -h oid.example.com -p 389 -D "cn=orcladmin" -q

Note:

The -q option prompts the user for a password. LDAP tools have been modified to disable the options -w password and -P password when the environment variable LDAP_PASSWORD_PROMPTONLY is set to TRUE or 1. Use this feature whenever possible.

For SSL:

ldapbind -h oidhost1.example.com -p 636 -D "cn=orcladmin" -q -U 1
ldapbind -h oidhost2.example.com -p 636 -D "cn=orcladmin" -q -U 1
ldapbind -h oid.example.com -p 636 -D "cn=orcladmin" -q -U 1

where -U is an optional argument used to specify the SSL authentication mode. These are the valid values for the SSL authentication mode:

  • 1 = No authentication required

  • 2 = One way authentication required. With this option, you must also supply a wallet location (-W "file:/home/my_dir/my_wallet") and wallet password (-P wallet_password).

  • 3 = Two way authentication required. With this option, you must also supply a wallet location (-W "file:/home/my_dir/my_wallet") and wallet password (-P wallet_password).

For more information about the ldapbind command, see the ldapbind section in Oracle Fusion Middleware Reference for Oracle Identity Management.

For information about setting up SSL for Oracle Internet Directory, see "Configuring Secure Sockets Layer (SSL)" in the Oracle Fusion Middleware Administrator's Guide for Oracle Virtual Directory manual.

WebLogic Server Administration Console:

http://oidhost1.example.com:7001/console

Oracle Enterprise Manager Fusion Middleware Console:

http://oidhost1.example.com:7001/em

8.3.6 Oracle Internet Directory Failover and Expected Behavior

This section includes steps for performing a failover of Oracle Internet Directory and for performing a failover of Oracle RAC.

This section includes the following topics:

8.3.6.1 Performing an Oracle Internet Directory Failover

Follow these steps to perform a failover of an Oracle Internet Directory instance and to check the status of Oracle Internet Directory:

  1. On OIDHOST1, use the opmnctl command to stop the Oracle Internet Directory instance:

    ORACLE_INSTANCE/bin/opmnctl stopproc ias-component=oid1

  2. On OIDHOST2, check the status of Oracle Internet Directory using the load balancing router:

    Note:

    See the "Configuring Your Environment" section of Oracle Fusion Middleware Reference for Oracle Identity Management for a list of the environment variables you must set before using the ldapbind command.

    ldapbind -h oid.example.com -p 389 -D "cn=orcladmin" -q

    Note:

    The -q option above prompts the user for a password. LDAP tools have been modified to disable the options -w password and -P password when the environment variable LDAP_PASSWORD_PROMPTONLY is set to TRUE or 1. Use this feature whenever possible.

  3. On OIDHOST1, use the opmnctl command to start the Oracle Internet Directory instance:

    ORACLE_INSTANCE/bin/opmnctl start (if OPMN is not running)
ORACLE_INSTANCE/bin/opmnctl startproc ias-component=oid1

  4. On OIDHOST2, use the opmnctl command to stop the Oracle Internet Directory instance:

    ORACLE_INSTANCE/bin/opmnctl stopproc ias-component=oid1

  5. On OIDHOST1, check the status of Oracle Internet Directory using the load balancing router:

    ldapbind -h oid.example.com -p 389 -D "cn=orcladmin" -q

  6. On OIDHOST2, use the opmnctl command to start the Oracle Internet Directory instance:

    ORACLE_INSTANCE/bin/opmnctl start (if OPMN is not running)
ORACLE_INSTANCE/bin/opmnctl startproc ias-component=oid1

8.3.6.2 Performing an Oracle RAC Failover

Follow these steps to perform an Oracle RAC failover:

  1. Use the srvctl command to stop the database instance that OID is using:

    srvctl stop instance -d db_unique_name -i inst_name_list

  2. Use the srvctl command to check the status of the database:

    srvctl status database -d db_unique_name -v

  3. Check the status of Oracle Internet Directory:

    Note:

    See the "Configuring Your Environment" section of Oracle Fusion Middleware Reference for Oracle Identity Management for a list of the environment variables you must set before using the ldapbind command.

    ldapbind -h oid_host -p 389 -D "cn=orcladmin" -q
ldapbind -h oid_host -p 389 -D "cn=orcladmin" -q
ldapbind -h oid.example.com -p 389 -D "cn=orcladmin" -q

    Note:

    The -q option above prompts the user for a password. LDAP tools have been modified to disable the options -w password and -P password when the environment variable LDAP_PASSWORD_PROMPTONLY is set to TRUE or 1. Use this feature whenever possible.

  4. Use the srvctl command to start the database instance:

    srvctl start instance -d db_unique_name -i inst_name_list

8.3.7 Troubleshooting Oracle Internet Directory High Availability

This section provides information that can help you troubleshoot Oracle Internet Directory high availability issues:

  • Log files for Oracle Internet Directory are found in the following directory:

    ORACLE_INSTANCE/diagnostics/log/OID/OIDcomponentname

  • The order in which log files should be examined when troubleshooting is:

    1. oidmon-xxx.log

    2. oidldapd01-xxxx.log

    3. oidldapd01s-xxxx.log

  • This section shows some of the error messages that may be related to high availability, and their meaning:

    Error: ORA-3112, ORA-3113 errors in the log file

    Cause: one of the database node is down, Oracle Internet Directory connects again to surviving node.

    Action: See why database node went down or Oracle process got killed

    Error: Failing Over...Please stand by in the log file

    Cause: Oracle Internet Directory server received a notification from the Oracle process that one of the database node is down. Oracle Internet Directory will connect to the surviving node.

    If the failover is successful you would see this message:

    Failover ended...resuming services.

    If the failover was not successful, you would see these errors:

    a. Tried 10 times, now quitting from failover function...

    b. Bad Failover Event:

    c. Forcing Failover abort as setting of DB parameters for the session failed

    If high availability event notification is enabled, you would see a message similar to the following:

    HA Callback Event
Thread Id: 8
Event type: 0
HA Source: OCI_HA_INSTANCE
Host name: dbhost1
Database name: orcl
Instance name: orcl1
Timestamp: 14-MAY-09 03.25.24 PM -07:00
Service name: orcl.example.com
HA status: DOWN - TAF Capable

    If TAF is disabled, HA status will be shown as "DOWN."

    Action: See why database node went down.

    Error: Time Difference of at least 250 sec found between node1 and node2.

    Cause: There is time difference between the two nodes

    Action: Synchronize the system time.

    Error: Node=% did not respond for configured %d times, Failing over...

    Cause: One of the Oracle Internet Directory nodes (oidmon) is not responding.

    Action: See if the node is alive or OIDMON process is running.

For more information about troubleshooting Oracle Internet Directory, see Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory.

8.3.8 Additional Oracle Internet Directory High Availability Issues

This section describes issues for Oracle Internet Directory in a high availability environment.

8.3.8.1 Changing the Password of the ODS Schema Used by Oracle Internet Directory

You can change the Oracle Internet Directory database schema password (that is, the password of the ODS user in the database) using the Oracle Internet Directory Database Password Utility (oidpasswd) from any Oracle Internet Directory node. However, since the ODS schema password is stored in a password wallet under the ORACLE_INSTANCE of each Oracle Internet Directory instance, the password wallet must be updated in each Oracle Internet Directory node.

To change the ODS database user password, invoke the following command on one of the Oracle Internet Directory nodes:

oidpasswd connect=database-connection-string change_oiddb_pwd=true

On all other Oracle Internet Directory nodes, invoke the following command to synchronize the password wallet:

oidpasswd connect=database-connection-string create_wallet=true

If you change the ODS password on one Oracle RAC node by using the Oracle Internet Directory Database Password Utility (oidpasswd), then you must do one of the following to update the wallet ORACLE_HOME/ldap/admin/oidpwdlldap1 on the other Oracle RAC nodes:

  • Invoke the OID Database Password Utility on all the other nodes to update the wallet file only. This applies to replication password changes also, but for replication password changes you would use the Replication Environment Management Tool to update the password instead of the OID Database Password Utility.

  • Copy the changed wallet to the other nodes.

If you run the oidpasswd command on one node only, and do not update the wallet on all the Oracle RAC nodes, the Oracle Internet Directory instance on the second node cannot start on the other nodes. You will see this error in the OIDMON log file:

[gsdsiConnect] ORA-1017, ORA-01017: invalid username/password; logon denied.

As mentioned above, the fix is to copy the oidpwdlldap1 file to the other Oracle RAC nodes, or to invoke the oidpasswd tool with the create_wallet=true option on the other nodes.

8.4 Oracle Virtual Directory High Availability

This section provides an introduction to Oracle Virtual Directory and describes how to design and deploy a high availability environment for Oracle Virtual Directory.

This section includes the following topics:

8.4.1 Oracle Virtual Directory Component Architecture

Oracle Virtual Directory is an LDAP version 3 enabled service that provides virtualized abstraction of one or more enterprise data sources into a single directory view. Oracle Virtual Directory provides the ability to integrate LDAP-aware applications into diverse directory environments while minimizing or eliminating the need to change either the infrastructure or the applications. See Overview in Oracle Fusion Middleware Administrator's Guide for Oracle Virtual Directory.

8.4.1.1 Oracle Virtual Directory Runtime Considerations

OPMN is used to start, monitor, and manage the Oracle Virtual Directory process, and to restart the Oracle Virtual Directory process if it goes down. For information on using OPMNCTL to start and stop Oracle Virtual Directory instances, see Oracle Fusion Middleware Administrator's Guide for Oracle Virtual Directory.

OPMN invokes the JVM to start the VDEServer process with the required parameters. JVM parameters are configured in opmn.xml. oracle.security.jps.config is used for the JPS Config File Location, vde.soTimeoutBackend is used to control orphan server connections.

You can also use the Oracle Enterprise Manager Fusion Middleware Control to start and stop Oracle Virtual Directory instances. For information, see Oracle Fusion Middleware Administrator's Guide for Oracle Virtual Directory.

Except for JPS, which is installed when Oracle Virtual Directory is installed, Oracle Virtual Directory does not have external dependencies. It can run by itself.

Oracle Virtual Directory can be configured to store LDAP objects in the local file system. This feature can be used by JPS and other components.

Oracle Virtual Directory provides two types of listeners: LDAP and HTTP. Both listeners support SSL/TLS on top of their basic protocols. The LDAP layer also provides the ability to support LDAP-SASL to support digital certificate authentication.

The LDAP(S) protocols provide LDAPv2/v3 based services, and the HTTP(S) protocols provide one or more services such as DSMLv2, or basic white page functions provided by an XSLT enabled Web Gateway.

Client connections can either be persistent or short-lived.

8.4.1.2 Oracle Virtual Directory Component Characteristics

This section describes the configuration artifacts for Oracle Virtual Directory. The following Oracle Virtual Directory configuration files are located under ORACLE_INSTANCE/config/OVD/OVDComponentName:

  • server.os_xml:

    Oracle Virtual Directory provides the ability to regulate items such as the number of entries the server can return for an anonymous user or for an authenticated user. You can also limit inbound transaction traffic, which can be used to protect proxied sources from Denial Of Service attacks or to limit LDAP traffic to control access to a limited directory infrastructure resource. These properties and others are configured in server.os_xml.

  • listeners.os_xml:

    Oracle Virtual Directory provides services to clients through connections known as Listeners. Oracle Virtual Directory supports two types of Listeners: LDAP and HTTP. An Oracle Virtual Directory configuration can have any number of listeners or it can even have zero Listeners, thus restricting access to only the administrative gateway. Most Oracle Virtual Directory deployments will need no more than two HTTP Listeners and two LDAP Listeners, where one Listener is for SSL and one for non-SSL for each protocol. The Listener configuration file is listeners.os_xml.

  • adapters.os_xml:

    To present the single virtual directory view of data in multiple and various data repositories, Oracle Virtual Directory must connect to those repositories so it can virtualize the data and route data to and from the repositories. Oracle Virtual Directory uses adapters to connect to its underlying data repositories. Each adapter manages a namespace in the directory identified by a specific parent distinguished name (DN). There is no limit to how many adapters you can configure. You can also combine and overlap adapters to present a customized directory tree. The adapters configuration file is adapters.os_xml.

    Note:

    To configure a No-Authorization SSL connection between Oracle Virtual Directory and a proxy LDAP directory, see Oracle Fusion Middleware Administrator's Guide for Oracle Virtual Directory. You can use the procedure for any proxy LDAP directory configured to support anonymous ciphers.

  • acls.os_xml

    Oracle Virtual Directory provides granular access controls that can be applied uniformly across all connected data stores and which are compliant with the Internet Engineering Task Force's RFC 2820, Access Control Requirements for LDAP. The access control rules are modeled on the IETF's internet draft titles LDAP Access Control Model for LDAPv3, (March 2, 2001 draft).

    Oracle Virtual Directory provides virtualized abstraction of one or more enterprise data sources into a single directory view. Accordingly, Access Control Lists (ACLs) and adapter namespaces are independent of each other. Removing all entries in a namespace, or changing the root value of an adapter, will not effect ACLs automatically. ACLs and adapter namespaces must be configured independently of each other. The ACL configuration file is acls.os_xml.

Oracle Virtual Directory instance-specific data is stored in the ORACLE_INSTANCE home. The wallet is also stored in the instance home.

If a single Oracle Virtual Directory instance fails, use OPMN to restart the instance.

8.4.1.2.1 Oracle Virtual Directory Log File

The log files for an Oracle Virtual Directory instance are stored in the following directory in the instance home:

ORACLE_INSTANCE/diagnostics/logs/OVD/OVDComponentName/

For more information on using the Oracle Virtual Directory log files to troubleshoot Oracle Virtual Directory issues, see Section 8.4.6, "Troubleshooting Oracle Virtual Directory High Availability".

8.4.2 Oracle Virtual Directory High Availability Concepts

This section provides conceptual information about using Oracle Virtual Directory in a high availability two-node cluster. See Section 8.4.2.2, "Oracle Virtual Directory Prerequisites" for prerequisites and Section 8.4.3, "Oracle Virtual Directory High Availability Configuration Steps" for specific steps for setting up the two-node cluster.

Note:

When you use both Oracle Internet Directory and Oracle Virtual Directory, these products typically reside in the same WebLogic domain.

8.4.2.1 Oracle Virtual Directory High Availability Architecture

Figure 8-5 shows the Oracle Virtual Directory high availability architecture in an active-active configuration.

Figure 8-5 Oracle Virtual Directory in a High Availability Environment

Description of Figure 8-5 follows
Description of "Figure 8-5 Oracle Virtual Directory in a High Availability Environment"

Figure 8-5 shows Oracle Virtual Directory in the directory tier in a high availability architecture. The two-node cluster is set up at installation time. The load balancing router routes requests to the two Oracle Virtual Directory instances that are clustered on OVDHOST1 and OVDHOST2. Fast Connection Failover (FCF) is used for notification when an Oracle RAC instance becomes unavailable.

The two computers have the same Oracle Virtual Directory configuration. The Oracle Virtual Directory configuration for each instance is stored in its ORACLE_INSTANCE. Each Oracle Virtual Directory Instance configuration must be updated separately by using Oracle Directory Services Manager to connect to each Oracle Virtual Directory instance one at a time. The alternate approach is to update the configuration of one Oracle Virtual Directory instance and then use cloning to copy the configuration to the other Oracle Virtual Directory instance or instances.

Note:

Oracle Directory Services Manager should be used to manage Oracle Virtual Directory configuration. Oracle Directory Services Manager should not connect to Oracle Virtual Directory through the load balancer to perform configuration updates to an Oracle Virtual Directory instance; instead, it should connect explicitly to a physical Oracle Virtual Directory instance to perform a configuration update for that instance.

OPMN is used to start and stop Oracle Virtual Directory instances. When a cluster that includes multiple Oracle Virtual Directory instances is started, there is no impact on the individual Oracle Virtual Directory instances in the cluster.

The load balancing router detects a hang or failure of an Oracle Virtual Directory instance and routes LDAP and HTTP traffic to surviving instances. When the instance becomes available again, the load balancing router detects this and routes traffic to all the surviving instances.

If an instance fails in the middle of a transaction, the transaction is not committed to the back end.

If one Oracle Virtual Directory instance in the two-node Oracle Virtual Directory cluster fails, the load balancing router detects this and reroutes the LDAP client traffic to the surviving instance or instances in the cluster. When the Oracle Virtual Directory instance comes up again, the load balancing router detects this and reroutes the LDAP client traffic instance to the surviving instance or instances in the cluster.

8.4.2.1.1 Oracle Virtual Directory High Availability Connect Features

Oracle Virtual Directory offers multiple high availability capabilities, including:

  • Fault Tolerance and Failover: Oracle Virtual Directories provide fault tolerance in two forms:

    • They can be configured in fault tolerant configurations.

    • They can manage flow to fault tolerant proxied sources.

    Multiple Oracle Virtual Directories can be quickly deployed by copying, or even sharing configuration files. When combined with round-robin DNS, redirector, or cluster technology, Oracle Virtual Directory provides a complete fault-tolerant solution.

    For each proxied directory source, Oracle Virtual Directory can be configured to access multiple hosts (replicas) for any particular source. It intelligently fails over between hosts and spreads the load between them. Flexible configuration options enable administrators to control percentages of a load to be directed towards specific replica nodes and to indicate whether a particular host is a read-only replica or a read-write server (master). This avoids unnecessary referrals resulting from attempts to write to a read-only replica.

  • Load Balancing: Oracle Virtual Directory was designed with powerful load balancing features that enable it to spread load and manage failures between its proxied LDAP directory sources.

    Oracle Virtual Directory's virtual directory tree capability enables large sets of directory information to be broken up into multiple distinct directory servers. Oracle Virtual Directory is able to recombine the separated data sets back into one virtual tree by combining the separate directory tree branches.

    If you have multiple LDAP servers for a particular source, the Oracle Virtual Directory LDAP Adapter can load balance and failover for these servers on its own. This load balancing and failover happens transparently to the client and does not require any additional hardware or changes to the client connecting to Oracle Virtual Directory.

    The Database adapter supports load balancing and failover if the underlying JDBC driver provides this functionality. Additionally, Oracle Virtual Directory is certified for use with Oracle Real Application Clusters (Oracle RAC). See Section 4.1.6, "JDBC Clients" for more information about using Oracle Virtual Directory with Oracle RAC.

    Oracle Virtual Directory Routing also provides load balancing capabilities. Routing enables search filters to be included in addition to the search base to determine optimized search targets. In this load balancing approach, Oracle Virtual Directory automatically routes queries to the appropriate virtualized directory sources enabling the ability to work with many millions of directory entries.

    Note:

    Oracle Virtual Directory's value is as a virtualization and proxy service, not as a directory store. If you need a highly available directory storage system, Oracle recommends using Oracle Internet Directory.

The log files for an Oracle Virtual Directory instance are stored in the following directory in the instance home:

ORACLE_INSTANCE/diagnostics/logs/OVD/OVDComponentName/

For more information on using the Oracle Virtual Directory log files to troubleshoot Oracle Virtual Directory issues, see Section 8.4.6, "Troubleshooting Oracle Virtual Directory High Availability".

8.4.2.2 Oracle Virtual Directory Prerequisites

This section describes prerequisites for Oracle Virtual Directory.

Note:

Oracle requires that you synchronize the system clocks on the cluster nodes when you are using Oracle Virtual Directory in a high availability deployment.

8.4.2.2.1 Load Balancer Virtual Server Names for Oracle Virtual Directory

When Oracle Virtual Directory is deployed in a high availability configuration, it is recommended to use an external load balancer to front-end the Oracle Virtual Directory instances and load balance the LDAP requests between the various Oracle Virtual Directory instances.

Refer to Section 8.2.5.4, "Configuring Virtual Server Names and Ports for the Load Balancer" for details.

8.4.3 Oracle Virtual Directory High Availability Configuration Steps

Oracle Virtual Directory can be deployed in a highly available configuration either in a standalone mode or as a part of a WebLogic Server domain.

Since Oracle Directory Services Manager and Oracle Enterprise Manager Fusion Middleware Control are required to manage Oracle Virtual Directory effectively, it is recommended that Oracle Virtual Directory be deployed as part of an WebLogic Server domain.

In a high availability environment, it is recommended that Oracle Virtual Directory be set up in a clustered deployment, where the clustered Oracle Virtual Directory instances access the same Oracle RAC database repository or LDAP repository.

8.4.3.1 Configuring Oracle Virtual Directory Without a WebLogic Domain

This section describes the steps to deploy Oracle Virtual Directory without a WebLogic Server domain.

Note:

When Oracle Virtual Directory is installed on a host using the Configure without a Domain option in the Oracle Identity Management 11g installer, by default the installer uses ovd1 as the component name for the Oracle Virtual Directory instance.

During a Configure without a Domain installation, the installer cannot detect if another Oracle Virtual Directory instance with a component name of ovd1 already exists on the host and is registered with a domain.

The Oracle Virtual Directory instances installed on OVDHOST1 and OVDHOST2 in Section 8.4.3.1.1, "Configuring Oracle Virtual Directory on OVDHOST1" and Section 8.4.3.1.2, "Configuring Oracle Virtual Directory on Additional Hosts (Scaling Out)" are installed using the Configure without a Domain installation option.

8.4.3.1.1 Configuring Oracle Virtual Directory on OVDHOST1

Follow these steps to configure the Oracle Virtual Directory instance on OVDHOST1:

  1. Ensure that the system, patch, kernel and other requirements are met. These are listed in Oracle Fusion Middleware Installation Guide for Oracle Identity Management in the Oracle Fusion Middleware documentation library.

  2. Ensure that Oracle Identity Management software is installed and upgraded on OVDHOST1 as Section 8.3.3.1, "Installing Oracle Fusion Middleware Components" describes.

  3. Ensure that the load balancer is configured as About Virtual Server Names Used by the Topologies in the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management describes.

  4. Ensure that ports 6501 and 7501 are not in use by any service on the computer by issuing these commands for the operating system you are using. If a port is not in use, no output is returned from the command.

    netstat -an | grep LISTEN | grep ":6501"

netstat -an | grep LISTEN | grep ":7501"

  5. If the port is in use (if the command returns output identifying the port), you must free the port.

    Remove the entries for ports 6501 and 7501 in the /etc/services file and restart the services, or restart the computer.

  6. Start the Oracle Identity Management 11g Configuration Wizard located under the ORACLE_HOME/bin directory as follows:

    ./config.sh

  7. On the Welcome screen, click Next.

  8. On the Select Domain screen, select Configure without a Domain then click Next.

  9. On the Specify Installation Location screen, specify the following values:

    • Oracle Middleware Home Location: This value is prefilled and cannot be changed.

    • Oracle Home Directory:

      /u01/app/oracle/product/fmw/idm_1

    • Oracle Instance Location:

      /u01/app/oracle/admin/ora_inst1

    • Oracle Instance Name:

      ora_inst1

      Note:

      Ensure that the Oracle Home Location directory path for OVDHOST1 is the same as the Oracle Home Location directory path for OVDHOST2. For example, if the Oracle Home Location directory path for OVDHOST1 is:

      /u01/app/oracle/product/fmw/idm_1

      then the Oracle Home Location directory path for OVDHOST2 must be:

      /u01/app/oracle/product/fmw/idm_1

    Click Next.

  10. On the Specify Email for Security Updates screen, specify these values:

    • Email Address: Provide the email address for your My Oracle Support account.

    • Oracle Support Password: Provide the password for your My Oracle Support account.

    • Check the checkbox next to the I wish to receive security updates via My Oracle Support field.

    Click Next.

  11. On the Configure Components screen, select Oracle Virtual Directory and click Next.

  12. On the Configure Ports screen, select Specify Ports Using Configuration File and enter the filename for the staticports.ini file that you copied to the temporary directory.

    Click Next.

  13. Specify the following values on the Specify Virtual Directory screen:

    In the Client Listeners section, enter:

    • LDAP v3 Name Space: Enter the name space for Oracle Virtual Directory.

      dc=example,dc=com

    • HTTP Web Gateway: Select this option to enable the Oracle Virtual Directory HTTP Web Gateway.

    • Secure: Select this option if you enabled the HTTP Web Gateway and you want to secure it using SSL.

    In the OVD Administrator section, enter:

    • Administrator User Name: Enter the user name for the Oracle Virtual Directory administrator, for example: cn=orcladmin

    • Password: Enter the password for the Oracle Virtual Directory administrator. For example: *******

    • Confirm Password: Confirm the password for the Oracle Virtual Directory administrator. For example: *******

    • Configure the Administrative Server in secure mode: Select this option to secure the Oracle Virtual Directory Administrative Listener using SSL. This option is selected by default. Oracle recommends selecting this option.

    Click Next.

  14. On the Installation Summary screen, review the selections to ensure that they are correct (if they are not, click Back to modify selections on previous screens), and click Install.

  15. On the Installation Progress screen on UNIX systems, a dialog box appears that prompts you to run the oracleRoot.sh script. Open a window and run the script, following the prompts in the window.

    Click Next.

  16. On the Configuration screen, multiple configuration assistants are launched in succession; this process can be lengthy. When it completes, click Next.

  17. On the Installation Complete screen, click Finish to confirm your choice to exit.

8.4.3.1.2 Configuring Oracle Virtual Directory on Additional Hosts (Scaling Out)

Follow these steps to configure the Oracle Virtual Directory instance on additional hosts. This procedure uses OVDHOST2 as an example:

Note:

You can also use the instructions in this topic to scale out Oracle Virtual Directory in your 11g Oracle Identity Management high availability configuration.

  1. Ensure that the system, patch, kernel and other requirements are met. These are listed in Oracle Fusion Middleware Installation Guide for Oracle Identity Management in the Oracle Fusion Middleware documentation library.

  2. Ensure that Oracle Identity Management software has been installed and upgraded on OVDHOST2 as described in Section 8.3.3.1, "Installing Oracle Fusion Middleware Components."

  3. On OVDHOST1, ports 6501 and 7501 were used for Oracle Virtual Directory. The same ports should be used for the Oracle Virtual Directory instance on OVDHOST2. Therefore, ensure that ports 6501 and 7501 are not in use by any service on OVDHOST2 by issuing these commands for the operating system you are using. If a port is not in use, no output is returned from the command.

    netstat -an | grep LISTEN | grep ":6501"

netstat -an | grep LISTEN | grep ":7501"

  4. If the port is in use (if the command returns output identifying the port), you must free the port.

    Remove the entries for ports 6501 and 7501 in the /etc/services file and restart the services, or restart the computer.

  5. Copy the staticports.ini file from the Disk1/stage/Response directory to a temporary directory.

  6. Edit the staticports.ini file that you copied to the temporary directory to assign the following custom ports (uncomment the lines where you specify the port numbers for Oracle Virtual Directory):

    # The Non-SSL LDAP port for OVD
Oracle Virtual Directory (Non-SSL) Port No for LDAP = 6501
# The SSL LDAP Port for OVD
Oracle Virtual Directory (SSL) Port No for LDAP = 7501

  7. Start the Configuration Wizard located under the ORACLE_HOME/bin directory as follows:

    ./config.sh

  8. On the Welcome screen, click Next.

  9. On the Select Domain screen, select Configure without a Domain and then click Next.

  10. On the Specify Installation Location screen, specify the following values:

    • Oracle Middleware Home Location: This value is prefilled and cannot be changed.

    • Oracle Home Directory:

      /u01/app/oracle/product/fmw/idm_1

    • Oracle Instance Location:

      /u01/app/oracle/admin/ora_inst2

    • Oracle Instance Name:

      ora_inst2

      Note:

      Ensure that the Oracle Home Location directory path for OVDHOST2 is the same as the Oracle Home Location directory path for OVDHOST1. For example, if the Oracle Home Location directory path for OVDHOST1 is:

      /u01/app/oracle/product/fmw/idm_1

      then the Oracle Home Location directory path for OVDHOST2 must be:

      /u01/app/oracle/product/fmw/idm_1

    Click Next.

  11. On the Specify Email for Security Updates screen, specify these values:

    • Email Address: Provide the email address for your My Oracle Support account.

    • Oracle Support Password: Provide the password for your My Oracle Support account.

    • Check the checkbox next to the I wish to receive security updates via My Oracle Support field.

    Click Next.

  12. On the Configure Components screen, select Oracle Virtual Directory and click Next.

  13. On the Configure Ports screen, select Specify Ports Using Configuration File and enter the filename for the staticports.ini file that you copied to the temporary directory.

    Click Next.

  14. Specify the following values on the Specify Virtual Directory screen:

    In the Client Listeners section, enter:

    • LDAP v3 Name Space: Enter the name space for Oracle Virtual Directory. The default value is dc=us,dc=example,dc=com.

      dc=us,dc=example,dc=com

    • HTTP Web Gateway: Select this option to enable the Oracle Virtual Directory HTTP Web Gateway.

    • Secure: Select this option if you enabled the HTTP Web Gateway and you want to secure it using SSL.

    In the OVD Administrator section, enter:

    • Administrator User Name: Enter the user name for the Oracle Virtual Directory administrator, for example: cn=orcladmin

    • Password: Enter the password for the Oracle Virtual Directory administrator. For example: *******

    • Confirm Password: Confirm the password for the Oracle Virtual Directory administrator. For example: *******

    • Configure the Administrative Server in secure mode: Select this option to secure the Oracle Virtual Directory Administrative Listener using SSL. This option is selected by default. Oracle recommends selecting this option.

    Click Next.

  15. On the Installation Summary screen, review the selections to ensure that they are correct (if they are not, click Back to modify selections on previous screens), and click Install.

  16. On the Installation Progress screen on UNIX systems, a dialog box appears that prompts you to run the oracleRoot.sh script. Open a window and run the script, following the prompts in the window.

    Click Next.

  17. On the Configuration screen, multiple configuration assistants are launched in succession; this process can be lengthy. When it completes, click Next.

  18. On the Installation Complete screen, click Finish to confirm your choice to exit.

8.4.3.1.3 Registering Oracle Virtual Directory with a WebLogic Domain

Oracle recommends managing Oracle Virtual Directory components with Oracle Enterprise Manager Fusion Middleware Control. To do this, you must register the component and the Oracle Fusion Middleware instance that contains it with a WebLogic Server domain. You can register an Oracle Fusion Middleware instance with a WebLogic domain during installation or Oracle instance creation, but you are not required to do so. If an Oracle Fusion Middleware instance was not previously registered with a WebLogic domain, you can register it by using opmnctl registerinstance.

Before using the opmnctl registerinstance command to register an Oracle Virtual Directory instance with a WebLogic Server domain, ensure that the WebLogic Server is installed.

Then run the opmnctl registerinstance command in this format (note that the ORACLE_HOME and ORACLE_INSTANCE variables have to be set for each installation before running this command in the home directory for the Oracle Virtual Directory instance):

opmnctl registerinstance -adminHost WLSHostName -adminPort WLSPort
-adminUsername adminUserName

For example:

opmnctl registerinstance -adminHost idmhost1.example.com -adminPort 7001
-adminUsername weblogic

Command requires login to weblogic admin server (idmhost1.example.com)
 Username: weblogic
 Password: *******

For additional details on registering components with a WebLogic domain, see the "Registering an Oracle Instance Using OPMNCTL" section in Oracle Fusion Middleware Administrator's Guide for Oracle Virtual Directory.

8.4.3.2 Configuring Oracle Virtual Directory With a WebLogic Domain

This section describes the steps to deploy Oracle Virtual Directory in a high availability configuration as part of a WebLogic Server domain.

In this configuration, Oracle Virtual Directory and a WebLogic Server domain is configured on the first host, and only Oracle Virtual Directory is configured on the second host. The Oracle Virtual Directory instance on the second host joins the domain created on the first host.

8.4.3.2.1 Configuring Oracle Virtual Directory on OVDHOST1

Follow these steps to configure the Oracle Virtual Directory instance on OVDHOST1:

  1. Ensure that the system, patch, kernel and other requirements are met. These are listed in Oracle Fusion Middleware Installation Guide for Oracle Identity Management in the Oracle Fusion Middleware documentation library.

  2. Ensure that Oracle Identity Management software has been installed and upgraded on OVDHOST1 as described in Section 8.3.3.1, "Installing Oracle Fusion Middleware Components."

  3. Ensure that ports 6501 and 7501 are not in use by any service on OVDHOST1 by issuing these commands for the operating system you are using. If a port is not in use, no output is returned from the command.

    netstat -an | grep LISTEN | grep ":6501"

netstat -an | grep LISTEN | grep ":7501"

  4. If the port is in use (if the command returns output identifying the port), you must free the port.

    Remove the entries for ports 6501 and 7501 in the /etc/services file and restart the services, or restart the computer.

  5. Copy the staticports.ini file from the Disk1/stage/Response directory to a temporary directory.

  6. Edit the staticports.ini file that you copied to the temporary directory to assign the following custom ports (uncomment the lines where you specify the port numbers for Oracle Virtual Directory):

    # The Non-SSL LDAP port for OVD
Oracle Virtual Directory (Non-SSL) Port No for LDAP = 6501
# The SSL LDAP port for OVD
Oracle Virtual Directory (SSL) Port No for LDAP = 7501

  7. Start the Configuration Wizard located under the ORACLE_HOME/bin directory as follows:

    ./config.sh

  8. On the Welcome screen, click Next.

  9. On the Select Domain screen, select Create New Domain and specify the following values:

    • User Name: weblogic

    • Password: <password for the weblogic user>

    • Confirm Password: <Confirm the password for the weblogic user>

    • Domain Name: IDMDomain

  10. On the Specify Installation Location screen, specify the following values:

    • Oracle Middleware Home Location:

      /u01/app/oracle/product/fmw

    • Oracle Home Directory: idm

    • WebLogic Server Directory:

      /u01/app/oracle/product/fmw/wlserver_10.3

    • Oracle Instance Location:

      /u01/app/oracle/admin/ovd_inst1

    • Oracle Instance Name:

      ovd_inst1

      Note:

      Ensure that the Oracle Home Location directory path for OVDHOST1 is the same as the Oracle Home Location directory path for OVDHOST2. For example, if the Oracle Home Location directory path for OVDHOST1 is:

      /u01/app/oracle/product/fmw/idm

      then the Oracle Home Location directory path for OVDHOST2 must be:

      /u01/app/oracle/product/fmw/idm

    Click Next.

  11. On the Specify Email for Security Updates screen, specify these values:

    • Email Address: Provide the email address for your My Oracle Support account.

    • Oracle Support Password: Provide the password for your My Oracle Support account.

    • Check the check box next to the I wish to receive security updates via My Oracle Support field.

    Click Next.

  12. On the Configure Components screen, select Oracle Virtual Directory and click Next.

    Note:

    The Oracle Directory Services Manager and Fusion Middleware Control management components are automatically selected for this installation. You cannot deselect these choices.

  13. On the Configure Ports screen, select Specify Ports Using Configuration File and enter the filename for the staticports.ini file that you copied to the temporary directory.

    Click Next.

  14. Specify the following values on the Specify Virtual Directory screen:

    In the Client Listeners section, enter:

    • LDAP v3 Name Space: Enter the name space for Oracle Virtual Directory. The default value is dc=us,dc=example,dc=com.

      dc=us,dc=example,dc=com

    • HTTP Web Gateway: Select this option to enable the Oracle Virtual Directory HTTP Web Gateway.

    • Secure: Select this option if you enabled the HTTP Web Gateway and you want to secure it using SSL.

    In the OVD Administrator section, enter:

    • Administrator User Name: Enter the user name for the Oracle Virtual Directory administrator, for example: cn=orcladmin

    • Password: Enter the password for the Oracle Virtual Directory administrator. For example: *******

    • Confirm Password: Confirm the password for the Oracle Virtual Directory administrator. For example: *******

    • Configure the Administrative Server in secure mode: Select this option to secure the Oracle Virtual Directory Administrative Listener using SSL. This option is selected by default. Oracle recommends selecting this option.

    Click Next.

  15. On the Installation Summary screen, review the selections to ensure that they are correct (if they are not, click Back to modify selections on previous screens), and click Install.

  16. On the Installation Progress screen on UNIX systems, a dialog box appears that prompts you to run the oracleRoot.sh script. Open a window and run the script, following the prompts in the window.

    Click Next.

  17. On the Configuration screen, multiple configuration assistants are launched in succession; this process can be lengthy. When it completes, click Next.

  18. On the Installation Complete screen, click Finish to confirm your choice to exit.

8.4.3.2.2 Creating boot.properties for the Administration Server on OVDHOST1

This section describes how to create a boot.properties file for the Administration Server on OVDHOST1. The boot.properties file enables the Administration Server to start without prompting for the administrator username and password.

Follow these steps to create the boot.properties file:

  1. On OVDHOST1, go the following directory:

    MW_HOME/user_projects/domains/domainName/servers/AdminServer/security

    For example:

    cd /u01/app/oracle/product/fmw/user_projects/domains/IDMDomain/servers/AdminServer/security

  2. Use a text editor to create a file called boot.properties under the security directory. Enter the following lines in the file:

    username=adminUser
password=adminUserPassword

    Note:

    When you start the Administration Server, the username and password entries in the file get encrypted.

    For security reasons, minimize the time the entries in the file are left unencrypted. After you edit the file, you should start the server as soon as possible so that the entries get encrypted.

  3. Stop the Administration Server if it is running.

    See the "Starting and Stopping Oracle Fusion Middleware" chapter of the Oracle Fusion Middleware Administrator's Guide for information on starting and stopping WebLogic Servers.

  4. Start the Administration Server on OVDHOST1 using the startWebLogic.sh script located under the MW_HOME/user_projects/domains/domainName/bin directory.

  5. Validate that the changes were successful by opening a web browser and accessing the following pages:

    • WebLogic Server Administration Console at:

      http://oidhost1.example.com:7001/console

    • Oracle Enterprise Manager Fusion Middleware Control at:

      http://oidhost1.example.com:7001/em

    Log into these consoles using the weblogic user credentials.

8.4.3.2.3 Configuring Oracle Virtual Directory on OVDHOST2

Follow these steps to configure the Oracle Virtual Directory instance on OVDHOST2:

  1. Ensure that the system, patch, kernel and other requirements are met. These are listed in Oracle Fusion Middleware Installation Guide for Oracle Identity Management in the Oracle Fusion Middleware documentation library for the version you are using.

  2. Ensure that Oracle Identity Management software has been installed and upgraded on OVDHOST2 as described in Section 8.3.3.1, "Installing Oracle Fusion Middleware Components."

  3. On OVDHOST1, ports 6501 and 7501 were used for Oracle Virtual Directory. The same ports should be used for the Oracle Virtual Directory instance on OVDHOST2. Therefore, ensure that ports 6501 and 7501 are not in use by any service on OVDHOST2 by issuing these commands for the operating system you are using. If a port is not in use, no output is returned from the command.

    netstat -an | grep LISTEN | grep ":6501"

netstat -an | grep LISTEN | grep ":7501"

  4. If the port is in use (if the command returns output identifying the port), you must free the port.

    Remove the entries for ports 6501 and 7501 in the /etc/services file and restart the services, or restart the computer.

  5. Copy the staticports.ini file from the Disk1/stage/Response directory to a temporary directory.

  6. Edit the staticports.ini file that you copied to the temporary directory to assign the following custom ports (uncomment the lines where you specify the port numbers for Oracle Virtual Directory):

    # The Non-SSL LDAP port for OVD
Oracle Virtual Directory (Non-SSL) Port No for LDAP = 6501
# The SSL LDAP port for OVD
Oracle Virtual Directory (SSL) Port No for LDAP = 7501

  7. Start the Configuration Wizard located under the ORACLE_HOME/bin directory as follows:

    ./config.sh

  8. On the Welcome screen, click Next.

  9. On the Select Domain screen, select Expand Cluster and specify the following values:

    • HostName: ovdhost1.example.com (This is the host where the Oracle WebLogic Administration Server is running.)

    • Port: 7001 (This is the Administration Server port.)

    • User Name: weblogic

    • Password: <password for the weblogic user>

  10. On the Specify Installation Location screen, specify the following values:

    • Oracle Middleware Home Location:

      /u01/app/oracle/product/fmw

    • Oracle Home Directory: idm

    • WebLogic Server Directory:

      /u01/app/oracle/product/fmw/wlserver_10.3

    • Oracle Instance Location:

      /u01/app/oracle/admin/ovd_inst2

    • Oracle Instance Name:

      ovd_inst2

      Note:

      Ensure that the Oracle Home Location directory path for OVDHOST1 is identical to the Oracle Home Location directory path for OVDHOST2. For example, if the Oracle Home Location directory path for OVDHOST1 is:

      /u01/app/oracle/product/fmw/idm

      then the Oracle Home Location directory path for OVDHOST2 must be:

      /u01/app/oracle/product/fmw/idm

    Click Next.

  11. On the Specify Email for Security Updates screen, specify these values:

    • Email Address: Provide the email address for your My Oracle Support account.

    • Oracle Support Password: Provide the password for your My Oracle Support account.

    • Check the checkbox next to the I wish to receive security updates via My Oracle Support field.

    Click Next.

  12. On the Configure Components screen, select Oracle Virtual Directory and click Next.

    Note:

    The Oracle Directory Services Manager and Fusion Middleware Control management components are automatically selected for the installation.

  13. On the Configure Ports screen, select Specify Ports Using Configuration File and enter the filename for the staticports.ini file that you copied to the temporary directory.

    Click Next.

  14. Specify the following values on the Specify Virtual Directory screen:

    In the Client Listeners section, enter:

    • LDAP v3 Name Space: Enter the name space for Oracle Virtual Directory. The default value is dc=example,dc=com.

      dc=example,dc=com

    • HTTP Web Gateway: Select this option to enable the Oracle Virtual Directory HTTP Web Gateway.

    • Secure: Select this option if you enabled the HTTP Web Gateway and you want to secure it using SSL.

    In the OVD Administrator section, enter:

    • Administrator User Name: Enter the user name for the Oracle Virtual Directory administrator, for example: cn=orcladmin

    • Password: Enter the password for the Oracle Virtual Directory administrator. For example: *******

    • Confirm Password: Confirm the password for the Oracle Virtual Directory administrator. For example: *******

    • Configure the Administrative Server in secure mode: Select this option to secure the Oracle Virtual Directory Administrative Listener using SSL. This option is selected by default. Oracle recommends selecting this option.

    Click Next.

  15. On the Installation Summary screen, review the selections to ensure that they are correct (if they are not, click Back to modify selections on previous screens), and click Install.

  16. On the Installation Progress screen on UNIX systems, a dialog box appears that prompts you to run the oracleRoot.sh script. Open a window and run the script, following the prompts in the window.

    Click Next.

  17. On the Configuration screen, multiple configuration assistants are launched in succession; this process can be lengthy. When it completes, click Next.

  18. On the Installation Complete screen, click Finish to confirm your choice to exit.

8.4.3.3 Configuring Oracle Virtual Directory with Highly Available Data Sources

Oracle Virtual Directory can be configured to use either an Oracle RAC database repository or a highly available LDAP repository as a data source.

This section describes how to configure Oracle Virtual Directory in a high availability environment with an Oracle RAC database repository and with an LDAP repository.

Note:

When configuring Oracle Virtual Directory in a high availability topology, the configuration steps must be completed on all the nodes individually.

8.4.3.3.1 Configuring Oracle Virtual Directory with an Oracle RAC Database

In an Oracle Virtual Directory high availability environment with an Oracle RAC database as the repository, you must create and configure an Oracle Virtual Directory Database Adapter.

For introductory information about Oracle Virtual Directory Adaptors, see the "Understanding Oracle Virtual Directory Adapters" section of Oracle Fusion Middleware Administrator's Guide for Oracle Virtual Directory.

For information about creating Database Adapters for Oracle RAC databases, see the "Creating Database Adapters for RAC Databases" section of Oracle Fusion Middleware Administrator's Guide for Oracle Virtual Directory.

For information about configuring Database Adapters, see the "Configuring Database Adapters" section of Oracle Fusion Middleware Administrator's Guide for Oracle Virtual Directory.

8.4.3.3.2 Configuring Oracle Virtual Directory with LDAP

Oracle Virtual Directory connects to a LDAP repository, such as Oracle Internet Directory, through an LDAP adapter. For high availability environments, the LDAP adapter can be configured by adding the host and port information of the nodes with a load balancing algorithm or by adding the load balancer URL of the LDAP repository.

For introductory information about Oracle Virtual Directory Adaptors, see the "Understanding Oracle Virtual Directory Adapters" section in Oracle Fusion Middleware Administrator's Guide for Oracle Virtual Directory.

For information about creating and configuring LDAP Adapters, see the "Configuring LDAP Adapters" section in Oracle Fusion Middleware Administrator's Guide for Oracle Virtual Directory.

8.4.4 Validating Oracle Virtual Directory High Availability

Oracle Virtual Directory instances are front-ended by a hardware load balancer in high availability deployments. Requests are load balanced between the Oracle Virtual Directory instances, and in case of a failure (either an instance failure or a host failure), the hardware load balancer detects the failure and routes all requests to the surviving instance or instances.

To test Oracle Virtual Directory high availability, stop one node at a time and connect to the Oracle Virtual Directory instances through the load balancer URL using a tool such as ldapbind. The connection should succeed all the time as long as one node is running and the topology is configured correctly.

Use the ldapbind command line tool to connect to the Oracle Virtual Directory instances through the load balancer virtual host. The ldapbind tool enables you to determine whether you can authenticate a client to a server.

To validate the high availability setup of Oracle Virtual Directory on OVDHOST1 and OVDHOST2:

  1. Configure your environment by following the steps in the "Configuring Your Environment" section of Oracle Fusion Middleware Reference for Oracle Identity Management. That section has a list of the environment variables you must set before using the ldapbind command.

  2. On OVDHOST1, use the opmnctl command to stop the Oracle Virtual Directory instance:

    ORACLE_INSTANCE/bin/opmnctl stopproc ias-component=ovd1

  3. On OVDHOST2, check the status of Oracle Virtual Directory by binding to the load balancing virtual address using ldapbind:

    Non-SSL:

    ldapbind -h ovd.example.com -p 6501 -D "cn=orcladmin" -q

    Note:

    The -q option above prompts the user for a password. LDAP tools have been modified to disable the options -w password and -P password when the environment variable LDAP_PASSWORD_PROMPTONLY is set to TRUE or 1. Use this feature whenever possible.

  4. A successful bind shows that the load balancer is routing all traffic to OVDHOST2.

  5. On OVDHOST1, use the opmnctl command to start the Oracle Virtual Directory instance:

    ORACLE_INSTANCE/bin/opmnctl start (if OPMN is not running)
ORACLE_INSTANCE/bin/opmnctl startproc ias-component=ovd1

  6. On OVDHOST2, use the opmnctl command to stop the Oracle Virtual Directory instance:

    ORACLE_INSTANCE/bin/opmnctl stopproc ias-component=ovd1

  7. On OVDHOST1, check the status of Oracle Virtual Directory by binding to the load balancing virtual address using ldapbind:

    Non-SSL:

    ldapbind -h ovd.example.com -p 6501 -D "cn=orcladmin" -q

  8. On OVDHOST2, use the opmnctl command to start the Oracle Virtual Directory instance:

    ORACLE_INSTANCE/bin/opmnctl start (if OPMN is not running)
ORACLE_INSTANCE/bin/opmnctl startproc ias-component=ovd1

For more information about the ldapbind command, see the ldapbind section in Oracle Fusion Middleware Reference for Oracle Identity Management.

8.4.4.1 Validating Oracle Virtual Directory High Availability Using SSL

Oracle Virtual Directory is configured to use the SSL Server Authentication Only Mode by default. When using command line tools like ldapbind to validate a connection using connection secured by SSL Server Authentication mode, the server certificate must be stored in an Oracle Wallet. Follow the steps below to perform this task:

  1. Create an Oracle Wallet by running the following command:

    ORACLE_HOME/bin/orapki wallet create -wallet DIRECTORY_FOR_SSL_WALLET -pwd WALLET_PASSWORD

  2. Export the Oracle Virtual Directory server certificate by running the following command:

    ORACLE_HOME/jdk/jre/bin/keytool -exportcert -keystore OVD_KEYSTORE_FILE
-storepass PASSWORD -alias OVD_SERVER_CERT_ALIAS -rfc -file
OVD_SERVER_CERT_FILE

  3. Add the Oracle Virtual Directory server certificate to the Oracle Wallet by running the following command:

    ORACLE_HOME/bin/orapki wallet add -wallet DIRECTORY_FOR_SSL_WALLET
-trusted_cert -cert OVD_SERVER_CERT_FILE -pwd WALLET_PASSWORD

  4. Follow the instructions shown in Section 8.4.4, "Validating Oracle Virtual Directory High Availability" but use the ldapbind command shown below to validate the high availability setup of Oracle Virtual Directory on OVDHOST1 and OVDHOST2. Use the Oracle Wallet from step 3 while running the following command:

    ORACLE_HOME/bin/ldapbind -D cn=orcladmin -q -U 2 -h HOST -p SSL_PORT -W "file://DIRECTORY_FOR_SSL_WALLET" -q

  5. When an Oracle Virtual Directory high availability deployment is front ended by a hardware load balancer, the wallets on all the Oracle Virtual Directory nodes must contain the client certificates of all the Oracle Virtual Directory instances that are a part of that topology. Add the client certificates of all the Oracle Virtual Directory instances in the topology to the wallets on all the nodes in the topology. This ensures that a valid connection request made through the load balancer URL does not fail.

    Note:

    If you are using default settings after installing 11g Release 1 (11.1.1), you can use the following values for the variables described in this section:

    • For OVD_KEYSTORE_FILE, use:

      ORACLE_INSTANCE/config/OVD/ovd1/keystores/keys.jks

    • For OVD_SERVER_CERT_ALIAS, use serverselfsigned

    • For PASSWORD used for the -storepass option, use the orcladmin account password.

8.4.5 Oracle Virtual Directory Failover and Expected Behavior

This section includes steps for performing a failover of Oracle Virtual Directory and for performing a failover of Oracle RAC.

8.4.5.1 Performing an Oracle Virtual Directory Failover

Follow these steps to perform a failover of an Oracle Virtual Directory instance and to check the status of Oracle Virtual Directory:

  1. Use the opmnctl command to stop the Oracle Virtual Directory instance:

    ORACLE_INSTANCE/bin/opmnctl stopproc ias-component=ovd1

  2. Use the opmnctl command to start the Oracle Virtual Directory instance:

    ORACLE_INSTANCE/bin/opmnctl start (if OPMN is not running)
ORACLE_INSTANCE/bin/opmnctl startproc ias-component=ovd1

  3. Check the status of Oracle Virtual Directory:

    ORACLE_INSTANCE/bin/opmnctl status ias-component=ovd1

8.4.5.2 Performing an Oracle RAC Failover

Follow these steps to perform an Oracle RAC failover:

  1. Use the srvctl command to stop a database instance:

    srvctl stop instance -d db_unique_name -i inst_name_list

  2. Use the srvctl command to check the status of the database:

    srvctl status database -d db_unique_name -v

  3. Check the status of Oracle Virtual Directory:

    ORACLE_INSTANCE/bin/opmnctl status ias-component=ovd1

  4. Use the srvctl command to start the database instance:

    srvctl start instance -d db_unique_name -i inst_name_list

    Note:

    When Oracle Virtual Directory is configured with a Database Adapter against an Oracle RAC database, the first search performed after the Oracle RAC failover fails. However, subsequent search requests succeed without any issues.

8.4.6 Troubleshooting Oracle Virtual Directory High Availability

Information in the Oracle Virtual Directory log files can be helpful in troubleshooting Oracle Virtual Directory issues. Log files for Oracle Virtual Directory are found under the following directory:

ORACLE_INSTANCE/diagnostics/log/OVD/<OVDComponentName>

The order in which log files should be examined when troubleshooting is:

  1. diagnostic.log: This file captures diagnostic messages.

  2. http-errors.log: This file captures HTTP errors.

  3. access.log: This file captures information about processes and clients that access the Oracle Virtual Directory instance.

8.4.6.1 Troubleshooting LDAP Adapter Creation

When creating an LDAP adapter, you specify the hostname and port number of LDAP server in the Connection page of adapter creation wizard. If the LDAP server is listening in SSL Server-Only Auth or Mutual Authentication mode, ODSM imports the server certificate into Oracle Virtual Directory's trust store. However, if you specify the load balancer name that front-ends more than one LDAP server, it imports only one of the LDAP server's certificates. This causes a problem when the Oracle Virtual Directory server's request is routed to the LDAP server, whose certificate is not trusted.

To avoid this problem, during LDAP adapter creation, in addition to specifying the load balancer host and port details, specify the host and port details of LDAP servers front-ended by the load balancer, so that certificates of all LDAP servers are imported. After the adapter is created, you can edit adapter settings to remove host and port details of physical LDAP servers, or their weight can be set to zero.

8.5 Oracle Directory Services Manager High Availability

This section introduces Oracle Directory Services Manager and describes how to design and deploy a high availability environment for Oracle Directory Integration Platform and Oracle Directory Services Manager.

See Section 8.6, "Oracle Directory Integration Platform High Availability" for more information about Oracle Directory Integration Platform.

This section includes the following topics:

8.5.1 Oracle Directory Services Manager Component Architecture

Oracle Directory Services Manager is a unified graphical user interface (GUI) for managing instances of Oracle Internet Directory and Oracle Virtual Directory. It replaces Oracle Directory Manager, which is now deprecated. Oracle Directory Services Manager enables you to configure the structure of the directory, define objects in the directory, as well as add and configure users, groups, and other entries.

Oracle Directory Services Manager is the interface used by end users to manage their directory entries, schemas, security, and other features.

Figure 8-6 shows the Oracle Directory Services Manager architecture.

Figure 8-6 Oracle Directory Services Manager Architecture

Description of Figure 8-6 follows
Description of "Figure 8-6 Oracle Directory Services Manager Architecture"

Figure 8-6 shows Oracle Directory Services Manager deployed in non-high availability architecture. Oracle Directory Services Manager is deployed on the WebLogic Server and is configured to communicate with the Oracle Virtual Directory and the Oracle Internet Directory instances it manages.

Oracle Directory Services Manager uses the HTTP(s) protocol to communicate with client browsers. It uses the LDAP(s) protocol to communicate with Oracle Internet Directory and over web services to communicate with Oracle Virtual Directory.

8.5.1.1 Oracle Directory Services Manager Component Characteristics

Oracle Directory Services Manager is an Oracle Application Development Framework (ADF)-based J2EE application that is deployed on top of the WebLogic Server. By default, Oracle Directory Services Manager deploys to the Administration Server within the WebLogic domain. Depending on the requirements in your environment, it can also be deployed to a Managed Server.

Oracle Directory Services Manager can be deployed on the same node with Oracle Internet Directory or on a separate node.

Oracle Directory Services Manager can be invoked directly or from Oracle Enterprise Manager Fusion Middleware Control. Supported browsers include Firefox 2, Firefox 3, and Internet Explorer 7.

To invoke Oracle Directory Services Manager directly, enter the following URL into your browser's address field:

http://host:port/odsm/faces/odsm.jspx

where:

  • host is the name of the Managed Server where Oracle Directory Services Manager is running.

  • port is the Managed Server port number.

To invoke Oracle Directory Services Manager from Oracle Enterprise Manager Fusion Middleware Control:

  • Select Directory Services Manager from the Oracle Internet Directory menu in the Oracle Internet Directory target, then Data Browser, Schema, Security, or Advanced.

  • From the Oracle Virtual Directory menu in the Oracle Virtual Directory target, select Directory Services Manager, then Data Browser, Schema, Adapter, Extensions, or Quick configuration wizard.

Oracle Directory Services Manager is deployed to an WebLogic Server as an externally staged application. The WebLogic server manages the startup, shutdown, monitoring of the Oracle Directory Services Manager application. Oracle Directory Services Manager initializes when the Managed Server starts up. Oracle Node Manager is configured to monitor the server process and restarts it in case of failure.

8.5.1.1.1 Lifecycle Management

The lifecycle events for the Oracle Directory Services Manager application can be managed using one or more of the command line tools and consoles listed below:

  • WebLogic Server Scripting Tool (WLST)

  • Oracle Enterprise Manager Fusion Middleware Control

  • WebLogic Server Administration Console

  • WebLogic Node Manager

8.5.1.1.2 Oracle Directory Services Manager Log File

Oracle Directory Services Manager messages are logged in the server log file of WebLogic Server where it is running. The default location of the server log is:

WEBLOGIC_SERVER_HOME/user_projects/domains/domainName/servers/serverName/logs/
serverName-diagnostic.log

8.5.2 Oracle Directory Services Manager High Availability Concepts

This section provides conceptual information about using Oracle Directory Services Manager in a high availability configuration.

In the Oracle Directory Services Manager high availability configuration described in this section, Oracle Directory Services Manager and Oracle Directory Integration Platform are installed and configured on two hosts in a two-node high availability active-active configuration.

8.5.2.1 Oracle Directory Services Manager High Availability Architecture

Figure 8-7 shows the Oracle Directory Integration Platform and Oracle Directory Services Manager high availability architecture in an active-active configuration.

Figure 8-7 Oracle Directory Services Manager and Oracle Directory Integration Platform in a High Availability Architecture

Description of Figure 8-7 follows
Description of "Figure 8-7 Oracle Directory Services Manager and Oracle Directory Integration Platform in a High Availability Architecture"

In Figure 8-7, the application tier includes the IDMHOST1 and IDMHOST2 computers.

On IDMHOST1, the following installations have been performed:

  • An Oracle Directory Integration Platform instance and Oracle Directory Services Manager instance have been installed on the WLS_ODS1 Managed Server. The Oracle RAC database has been configured in a JDBC multi data source to protect the instances from Oracle RAC node failure.

  • A WebLogic Administration Server has been installed. Under normal operations, this is the active Administration Server.

On IDMHOST2, the following installations have been performed:

  • An Oracle Directory Integration Platform instance and Oracle Directory Services Manager instance have been installed in the WLS_ODS2 Managed Server. The Oracle RAC database has been configured in a JDBC multi data source to protect the instances from Oracle RAC node failure.

    The instances in the WLS_ODS2 Managed Server on IDMHOST2 and the instances in the WLS_ODS1 Managed Server on IDMHOST1 are configured as the CLUSTER_ODS cluster.

  • A WebLogic Administration Server has been installed. Under normal operations, this is the passive Administration Server. You will make this Administration Server active if the Administration Server on IDMHOST1 becomes unavailable.

8.5.2.1.1 Starting and Stopping the Cluster

In a high availability architecture, Oracle Directory Integration Platform and Oracle Directory Services Manager are deployed on an Oracle WebLogic Cluster that has at least two servers as a part of the cluster.

By default, the WebLogic Server starts, stops and monitors the applications. By default, both the Oracle Directory Integration Platform and Oracle Directory Services Manager applications leverage the high availability features of the underlying WebLogic Clusters. In case of hardware or other failures, session state is available to other cluster nodes that can resume the work of the failed node.

In a high availability environment, WebLogic Node Manager is configured to monitor the WebLogic servers. In case of failure, Node Manager restarts the WebLogic Server. If Node Manager cannot restart the server, then the front-ending load balancing router detects failure of a WebLogic instance in the Cluster and routes traffic to surviving instances.

8.5.2.2 Protection from Failures and Expected Behaviors

This section describes protection from different types of failure in an Oracle Directory Services Manager active-active cluster.

8.5.2.2.1 Process Failure

In a high availability environment, the Oracle Directory Services Manager applications are deployed on a WebLogic Server cluster comprised of at least two WebLogic instances.

By default, the Oracle Directory Services Manager applications leverage the high availability features of the underlying WebLogic Clusters. In case of hardware or other failures, session state is available to other cluster nodes that can resume the work of the failed node.

In addition, in a high availability environment, WebLogic Node Manager is configured to monitor the WebLogic servers. In case of failure, Node Manager restarts the WebLogic Server. If Node Manager cannot restart the server, then mod_wl_ohs.conf, which is configured as a part of Oracle HTTP Server, routes the request to the surviving WebLogic instance.

OPMN monitors the Oracle HTTP Server processes and restarts the process in case of failure. If OPMN is unable to restart the HTTP process, the front-ending load balancing router detects the failure of an Oracle HTTP Server instance and routes traffic to surviving instances.

Oracle Directory Services Manager maintains a session state, but in case of failure, the session state information is not carried over to the surviving node.

8.5.2.2.2 Expected Client Application Behavior When Failure Occurs

Oracle Directory Services Manager failover is not transparent. You have to reestablish the connection during an WebLogic Server instance failover using Oracle Directory Services Manager.

8.5.2.2.3 Expected Dependency Failure

Oracle Directory Services Manager requires the WebLogic Managed Server to be available during startup. If it is not available, Oracle Directory Services Manager fails to start.

8.5.2.3 Oracle Directory Services Manager Prerequisites

This section describes prerequisites for setting up Oracle Directory Services Manager in the high availability architecture.

Note:

Oracle requires that you synchronize the system clocks on the cluster nodes when you are using Oracle Directory Services Manager in a high availability deployment.

Oracle recommends that you install and configure the components listed below before you install Oracle Directory Services Manager. See the sections below for the prerequisites as well as installation and configuration steps:

8.5.3 Oracle Directory Services Manager High Availability Configuration Steps

See Section 8.6.3, "Oracle Directory Integration Platform High Availability Configuration Steps" for the steps for installing and configuring the high availability active-active configuration shown in Figure 8-7.

Note:

Oracle Directory Services Manager requires Oracle WebLogic Server. See Section 8.3.3.1.1, "Install Oracle WebLogic Server" for installation instructions.

8.5.4 Validating Oracle Directory Services Manager High Availability

This section describes how to validate Oracle Directory Services Manager in a high availability configuration.

Topics in the section include the following:

8.5.4.1 Performing a WebLogic Server Instance Failover

While you are accessing Oracle Directory Services Manager through Oracle HTTP Server, you can use the steps in this section to fail over a WebLogic Server instance and validate that Oracle Directory Services Manager is still accessible.

The Oracle HTTP Server virtual server name in this example is:

http://idmhost1:odsmport/odsm

Perform these steps:

  1. Access Oracle Directory Services Manager through the Oracle HTTP Server virtual server name:

    http://idmhost1:odsmport/odsm

  2. When the Welcome to Oracle Directory Services Manager screen is displayed, open a web browser and enter the following URL:

    http://hostname:port/console

    where hostname is the DNS name of the Administration Server and port is the address of the port on which the Administration Server is listening for requests (7001 by default).

  3. On the login page, enter the user name and the password you used to start the Administration Server and click Log In.

  4. Shut down one of the Managed Servers where Oracle Directory Services Manager is deployed by following these steps:

    1. In the left pane of the Administration Console, expand Environment and select Servers.

      See the "Starting and Stopping Oracle Fusion Middleware" chapter of the Oracle Fusion Middleware Administrator's Guide for information on starting and stopping WebLogic Servers.

    2. Click the name of the Managed Server that you want to shut down. For example, wls_ods1.

    3. In the settings for wls_ods1 screen, select the Control --> Start/Stop tab.

    4. Select the check box next to the name of the Managed Server (wls_ods1) that you want to shut down and click Shutdown > When work completes.

  5. Check the status of the Managed Server (wls_ods1):

    1. In the left pane of the Console, expand Environment and select Servers.

    2. The State for the Managed Server (wls_ods1) should be SHUTDOWN.

  6. Access Oracle Directory Services Manager through the Oracle HTTP Server virtual server name:

    http://idmhost1:odsmport/odsm

    The Welcome to Oracle Directory Services Manager screen opens.

8.5.4.2 Performing an Oracle RAC Database Failover

While you are accessing Oracle Directory Services Manager through the load balancing router, you can follow the steps in this section to fail over one Oracle RAC database instance at a time and ensure that Oracle Directory Services Manager is still functional. This example checks Oracle Directory Services Manager as well as Oracle Internet Directory access to the database.

The Oracle HTTP Server virtual server name in this example is:

http://idmhost1:odsmport/odsm

The LDAP virtual server name in this example is:

oid.example.com:389

Perform these steps:

  1. Access Oracle Directory Services Manager through the Oracle HTTP Server virtual server name:

    http://idmhost1:odsmport/odsm

    The Welcome to Oracle Directory Services Manager screen is displayed.

  2. Verify that you can connect to Oracle Internet Directory using the LDAP virtual server:

    1. Select the Connect to a directory --> Create A New Connection link in the upper right hand corner.

    2. In the New Connection screen, fill in the connection information below and click Connect:

      • Directory Type: OID

      • Name: OIDHA

      • Server: oid.example.com

      • Port: 389

      • SSL Enabled: Leave blank

      • User Name: cn=orcladmin

      • Password: ********

      • Start Page: Home (default)

  3. Shut down the Oracle Internet Directory Schema database instance on INFRADBHOST1-VIP by running the following srvctl commands (in this example, the database name is INFRADB):

    ORACLE_HOME/bin/srvctl stop instance -d infradb -i infradb1
ORACLE_HOME/bin/srvctl status database

  4. Refresh the Oracle Directory Services Manager screen or go to one of the tabs (Home, Data Browser, Schema, Security, Advanced). You should still be able to access the Oracle Internet Directory information.

  5. Restart the Oracle Internet Directory Schema database instance on INFRADBHOST1-VIP by running the following srvctl commands:

    ORACLE_HOME/bin/srvctl start instance -d infradb -i infradb1
ORACLE_HOME/bin/srvctl status database

  6. Repeat steps 3, 4, and 5 for INFRADBHOST2-VIP.

8.5.5 Oracle Directory Services Manager Failover and Expected Behavior

This section provides steps for using Oracle Directory Services Manager to validate a failover of a Managed Server, to validate a failover of an Oracle Internet Directory instance, and to validate a failover of an Oracle RAC database.

This section includes the following topics:

8.5.5.1 Using Oracle Directory Services Manager to Validate a Failover of a Managed Server

To use Oracle Directory Services Manager to validate a failover of a Managed Server:

  1. In a web browser, launch the Oracle Directory Services Manager page using the Oracle HTTP Server host and port. For example:

    http://WEBHOST1:PORT/odsm/faces/odsm.jspx

  2. Make a connection to Oracle Internet Directory.

  3. Go to the Administration Console and stop the wls_ods1 Managed Server.

  4. Go back to the Oracle Directory Services Manager page and continue your work.

  5. The Oracle Directory Services Manager page will be disconnected.

  6. Re-launch the Oracle Directory Services Manager page using the Oracle HTTP Server host and port again from the same browser.

  7. Reestablish a new connection.

The current behavior is the expected behavior. Oracle Directory Services Manager failover is not transparent. You must reestablish the connection during a WebLogic Server instance failover using Oracle Directory Services Manager.

8.5.5.2 Using Oracle Directory Services Manager to Validate a Failover of an Oracle Internet Directory Instance

To use Oracle Directory Services Manager to validate a failover of an Oracle Internet Directory instance:

  1. In a web browser, launch the Oracle Directory Services Manager page using the Oracle HTTP Server host and port. For example:

    http://WEBHOST1:PORT/odsm/faces/odsm.jspx

  2. Make a connection to the Oracle Internet Directory hardware load balancer.

  3. Shut down one Oracle Internet Directory instance at a time.

  4. During the failover, go back to the Oracle Directory Services Manager page and continue your work.

It is expected behavior when Oracle Directory Services Manager opens a window with a message that Oracle Internet Directory is down. Oracle Directory Services Manager reconnects to Oracle Internet Directory but the connection may not persist during the failover. For additional information, see Section 8.5.6.4, "Oracle Directory Services Manager Displays "LDAP Server is down" Message During Oracle Internet Directory Failover."

While accessing Oracle Directory Services Manager, fail over the Oracle Internet Directory instances one at a time and ensure the LDAP store is still accessible. Oracle Directory Services Manager might not have a persistent connection to Oracle Internet Directory.

8.5.5.3 Using Oracle Directory Services Manager to Validate an Oracle RAC Failover

To use Oracle Directory Services Manager to validate an Oracle RAC failover:

  1. In a web browser, launch the Oracle Directory Services Manager page using the Oracle HTTP Server host and port. For example:

    http://WEBHOST1:PORT/odsm/faces/odsm.jspx

  2. Connect to the Oracle Internet Directory from the Oracle Directory Services Manager page.

  3. Shut down one Oracle RAC database instance at a time.

  4. Go back to the Oracle Directory Services Manager page and continue your work from the Oracle Internet Directory connection established in Step 2.

It is expected behavior for Oracle Directory Services Manager to temporarily lose its connection during an Oracle RAC failover. See Section 8.5.6.5, "Oracle Directory Services Manager Temporarily Loses Its Connection During Oracle RAC Failover" for more information about the error message that opens in Oracle Directory Services Manager during an Oracle RAC failover.

While accessing Oracle Directory Services Manager through the hardware load balancer, perform a failover on one Oracle RAC database instance at a time and ensure that Oracle Directory Services Manager is still functional. This will check Oracle Directory Services Manager as well as Oracle Internet Directory access to the Oracle RAC database.

8.5.6 Troubleshooting Oracle Directory Services Manager

This section describes how to deal with issues involving Oracle Directory Services Manager high availability.

8.5.6.1 Dealing with Error Messages Received After Starting WebLogic Node Manager

If the following error message appears after you start WebLogic Node Manager, follow the steps that appear below after the error message:

<Dec 15, 2008 8:40:05 PM> <Warning> <Uncaught exception in server handler:
javax.net.ssl.SSLKeyException: [Security:090482]BAD_CERTIFICATE alert was
received from stbee21.example.com - 152.68.64.2155. Check the peer to 
determine why it rejected the certificate chain (trusted CA configuration,
hostname verification). SSL debug tracing may be required to determine the
exact reason the certificate was rejected.> javax.net.ssl.SSLKeyException:
[Security:090482]BAD_CERTIFICATE alert was received from stbee21.example.com -
152.68.64.215. Check the peer to determine why it rejected the certificate chain 
(trusted CA configuration, hostname verification). SSL debug tracing may be
required to determine the exact reason the certificate was rejected.

  1. If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit.

  2. In the left pane of the Console, expand Servers and AdminServer (admin).

  3. Select the Configuration > SSL > Advanced Link.

  4. Select None for Hostname Verification.

  5. Click Save.

  6. Click Activate Changes in the Change Center of the Administration Console.

  7. Restart all servers.

If the Managed Server is started in Admin mode, perform these steps:

  1. If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit.

  2. In the left pane of the Console, expand Servers and the name of the server that is running in ADMIN mode.

  3. Select the Control > Start/Stop tab.

  4. Select the name of the server. Click Resume.

  5. Select Yes to resume servers.

8.5.6.2 WebLogic Node Manager Fails to Start

If WebLogic Node Manager fails to start, ensure that you copied the following domains file from IDMHOST1 to IDMHOST2:

WL_HOME/common/nodemanager/nodemanager.domains

8.5.6.3 Oracle Directory Services Manager Failover Using Oracle HTTP Server is Not Transparent

When you perform an Oracle Directory Services Manager failover using Oracle HTTP Server, the failover is not transparent. You see this behavior when you perform the following steps:

  1. Oracle Directory Services Manager is deployed in a high availability active-active configuration using Oracle HTTP Server.

  2. Open an Oracle Directory Services Manager page using the Oracle HTTP Server name and port number.

  3. Make a connection to an LDAP server, for example, an Oracle Internet Directory server or an Oracle Virtual Directory server.

  4. Work with the LDAP server using the current Oracle Directory Services Manager Oracle HTTP Server host and port.

  5. Shut down one Managed Server at a time using the Administration Console.

  6. Go back to the Oracle Directory Services Manager page and port, and the connection which was established earlier with Oracle Internet Directory or Oracle Virtual Directory. When you do, a message is displayed advising you to reestablish a new connection to the Oracle Directory Services Manager page.

In this situation, you must do the following:

  1. In your web browser, exit the current Oracle Directory Services Manager page.

  2. Launch a new web browser page and specify the same Oracle Directory Services Manager Oracle HTTP Server name and port.

  3. Reestablish a new connection to the LDAP server you were working with earlier (Oracle Internet Directory or Oracle Virtual Directory).

8.5.6.4 Oracle Directory Services Manager Displays "LDAP Server is down" Message During Oracle Internet Directory Failover

In a high availability configuration where Oracle Directory Services Manager is connected to Oracle Internet Directory through a load balancer, Oracle Directory Services Manager opens the LDAP Server is down message during failover from one instance of Oracle Internet Directory to another.

The connection reestablishes less than a minute after the Oracle Internet Directory failover is complete and you can continue without logging in again.

8.5.6.5 Oracle Directory Services Manager Temporarily Loses Its Connection During Oracle RAC Failover

Oracle Directory Services Manager temporarily loses its connection to an Oracle Internet Directory instance that is using an Oracle RAC database during an Oracle RAC failover. Oracle Directory Services Manager may display the message Failure accessing Oracle database (oracle errcode=errcode), where errcode is one of the following values: 3113, 3114, 1092, 28, 1041, or 1012.

The connection will be reestablished in less than a minute after the Oracle RAC failover is complete, and you will be able to continue without logging in again.

8.5.7 Additional Considerations for Oracle Directory Services Manager High Availability

When using Oracle Directory Services Manager to manage an Oracle Internet Directory cluster, use the load balancer virtual address as the connect string. However, when using Oracle Directory Services Manager to manage an Oracle Virtual Directory cluster, you must specify the hostname and port for a specific Oracle Virtual Directory instance.

8.6 Oracle Directory Integration Platform High Availability

This section provides an introduction to Oracle Directory Integration Platform and describes how to design and deploy a high availability environment for Oracle Directory Integration Platform and Oracle Directory Services Manager.

See Section 8.5, "Oracle Directory Services Manager High Availability" for more information about Oracle Directory Services Manager.

Note:

You must have a WebLogic domain for Oracle Directory Integration Platform.

This section includes the following topics:

8.6.1 Oracle Directory Integration Platform Component Architecture

Oracle Directory Integration Platform is a J2EE application that enables you to integrate your applications and directories, including third-party LDAP directories, with Oracle Internet Directory.

Oracle Directory Integration Platform includes services and interfaces that enable you to deploy synchronization solutions with other enterprise repositories. It can also be used to provide Oracle Internet Directory interoperability with third party metadirectory solutions.

Oracle Directory Integration Platform provides two distinct services depending on the type of integration needed:

  • Synchronization through the Oracle Directory Integration Platform Synchronization Service, which keeps connected directories consistent with the central Oracle Internet Directory.

  • Notification through Oracle Directory Integration Platform Provisioning Service, which sends notifications to target applications periodically to reflect changes made to a user's status or information.

    Note:

    Throughout the rest of this chapter, these terms will be used:

    • "Synchronization Service" for Oracle Directory Integration Platform Synchronization Service

    • "Provisioning Service" for Oracle Directory Integration Platform Provisioning Service

Figure 8-8 shows the Oracle Directory Integration Platform architecture.

Figure 8-8 Oracle Directory Integration Platform Architecture

Description of Figure 8-8 follows
Description of "Figure 8-8 Oracle Directory Integration Platform Architecture"

Figure 8-8 shows the various components of Oracle Directory Integration Platform. Oracle Internet Directory is synchronized with connected directories using Oracle Directory Integration Platform's Synchronization Enterprise JavaBeans (EJB) and the Quartz Scheduler.

Similarly, changes in Oracle Internet Directory are sent to various applications using Oracle Directory Integration Platform's Provisioning Enterprise JavaBeans (EJB) and the Quartz Scheduler.

8.6.1.1 Oracle Directory Integration Platform Component Characteristics

Oracle Directory Integration Platform is a J2EE application that enables you to integrate your applications and directories, including third-party LDAP directories, with Oracle Internet Directory.

Oracle Directory Integration Server provides synchronization services through the Synchronization Service and integration services through the Provisioning Service, as described below:

  • The Synchronization Service provides:

    • Scheduling: Processing a synchronization profile based on a predefined schedule

    • Mapping: Running rules for converting data between connected directories and Oracle Internet Directory

    • Data propagation: Exchanging data with connected directories by using a connector

    • Error handling

  • The Provisioning Service provides:

    • Data propagation: Exchanging data with connected directories by using a connector

    • Event notification: Notifying an application of a relevant change to the user or group data stored in Oracle Internet Directory

    • Error handling

Oracle Directory Integration Platform is deployed on WebLogic Server. By default, Oracle Directory Integration Platform is installed as part of the Oracle Identity Management software stack; however, depending on your architectural requirements, it can also be installed as a standalone application.

8.6.1.1.1 Runtime Processes

The Oracle Directory Integration Server provides:

  • The Synchronization Service using the Synchronization Enterprise JavaBeans (EJB) and the Quartz Scheduler. The Synchronization EJB is stateless in nature.

    The Quartz scheduler invokes the Synchronization EJBs that synchronize the appropriate change to all the connected directories.

    The Synchronization Service supplies these changes using the interface and format required by the connected directory. Synchronization through the Oracle Directory Integration Platform connectors ensures that Oracle Internet Directory remains up-to-date with all the information that Oracle Internet Directory clients need.

  • The Provisioning Service uses the Provisioning Enterprise JavaBeans (EJB) and the Quartz Scheduler. The Provisioning EJB is stateless in nature.

    The Quartz scheduler invokes the Provisioning EJBs that in turn notify each of the provisioned application of the changes.

  • UpdateJob EJB periodically polls the Oracle Internet Directory changelog for changes in the Synchronization or Provisioning Profiles. When a profile change is detected, the Quartz scheduler jobs are updated accordingly.

8.6.1.1.2 Process Lifecycle

Oracle Directory Integration Platform deploys to a WebLogic Server as an externally managed application. By default, the Oracle Directory Integration Platform application leverages the underlying WebLogic Server infrastructure for startup, shutdown, monitoring and other lifecycle events. You can configure WebLogic Node Manager to monitor the server process and restart it in case of failure.

Oracle Directory Integration Platform initializes when the Managed Server it is deployed on starts up. After the Oracle Directory Integration Platform application starts up, the initialization code creates an initial set of jobs for the existing directory integration profiles and then invokes the UpdateJobBean EJB.

UpdateJobBean updates the jobs submitted to the Quartz Scheduler.

Depending upon the job, the Quartz scheduler invokes either the Provisioning EJB or the Synchronization EJB. If the Provisioning EJB is invoked, it, in turn, notifies each of the provisioned application of Oracle Internet Directory changes. If the Synchronization EJB is invoked, it, in turn, synchronizes the appropriate change to all the connected directories.

Starting and Stopping

Manage Oracle Directory Integration Platform lifecycle events using one or more of the command line tools and consoles listed below:

  • Oracle WebLogic Scripting Tool (WLST)

  • Oracle Enterprise Manager Fusion Middleware Control

  • WebLogic Server Administration Console

  • Oracle WebLogic Node Manager

8.6.1.1.3 Request Flow

Oracle Directory Integration Platform does not service any external requests. Its main functionality is to support synchronization or provisioning based on the profiles created.

This section describes the information flow during synchronization and provisioning.

Oracle Directory Integration Platform Synchronization Service Flow

Oracle Directory Integration Platform relies on the directory synchronization profiles to synchronize changes between Oracle Internet Directory and the connected directories.

Depending on where the changes are made, synchronization can occur:

  • From a connected directory to Oracle Internet Directory

  • From Oracle Internet Directory to a connected directory

  • In both directions

Synchronizing from Oracle Internet Directory to a Connected Directory

Oracle Internet Directory maintains a change log in which it stores incremental changes made to directory objects. It stores these changes sequentially based on the change log number.

Synchronization from Oracle Internet Directory to a connected directory makes use of this change log. Consequently, when running the Oracle Directory Integration Platform, you must start Oracle Internet Directory with the default setting in which change logging is enabled.

Each time the Oracle Directory Integration Platform Synchronization Service processes a synchronization profile, it:

  1. Retrieves the latest change log number up to which all changes have been applied.

  2. Checks each change log entry more recent than that number.

  3. Selects changes to be synchronized with the connected directory by using the filtering rules in the profile.

  4. Applies the mapping rules to the entry and makes the corresponding changes in the connected directory.

The appropriate entries or attributes are then updated in that connected directory. If the connected directory does not use DB, LDAP, tagged, or LDIF formats directly, then the agent identified in its profile is invoked. The number of the last change successfully used is then stored in the profile.

Periodically, Oracle Internet Directory purges the change log after all profiles have used what they need, and identifies where subsequent synchronization should begin.

Synchronizing from a Connected Directory to Oracle Internet Directory

When a connected directory uses DB, LDAP, tagged, or LDIF formats directly, changes to its entries or attributes can be automatically synchronized by the Oracle Directory Integration Platform Synchronization Service. Otherwise, the connector has an agent in its synchronization profile, which writes the changes to a file in the LDIF or tagged format. The Oracle Directory Integration Platform Synchronization Service then uses this file of connected directory data to update Oracle Internet Directory.

Provisioning Flow

Provisioning refers to the process of providing users, groups, and other objects with access to applications and other resources that are available within an environment. A provisioning-integrated application refers to an application that has registered for provisioning events and registered a provisioning-integration profile in Oracle Internet Directory.

An application can be provisioned with Oracle Directory Integration Platform Provisioning in one of the methods below:

  • Synchronous provisioning

  • Asynchronous provisioning

  • Provisioning data flow

Each of these provisioning methods is described in its own section below.

Synchronous Provisioning

Applications that maintain user information in Oracle Internet Directory and use the Data Access Java plug-in to create, modify, and delete user entries whenever the change occurs in Oracle Internet Directory are said to be provisioned synchronously, since the Data Access Java plug-in can be invoked directly from Oracle Identity Management, including the Provisioning Console and command-line LDAP tools.

Synchronous provisioning with the Oracle Directory Integration Platform Provisioning Service can be invoked from Oracle Identity Management Tools (such as the Provisioning Console in the Oracle Fusion Middleware Control and bulkprov), synchronization with third-party directories, or command-line LDAP tools.

Synchronous provisioning with the Oracle Directory Integration Platform Provisioning Service from Oracle Identity Management Tools such as through the Provisioning Console screen in the Oracle Fusion Middleware Control, bulk provisioning with the provProfileBulkProv command, and from third-party directories follows this process:

  1. A new user entry is created in Oracle Internet Directory.

  2. The Oracle Identity Management component that created the new user entry invokes the Data Access Java plug-in.

  3. The Data Access Java plug-in provisions the new user account in the application.

Synchronous provisioning from command line LDAP tools follows this process:

  1. A command-line LDAP tool creates a new user entry in Oracle Internet Directory.

  2. At the next scheduled synchronization interval, the Oracle Directory Integration Platform identifies new user entries in Oracle Internet Directory that require provisioning.

  3. The Oracle Directory Integration Platform invokes the Data Access Java plug-in.

  4. The Data Access Java plug-in provisions the new user accounts in the application.

Asynchronous Provisioning

In asynchronous provisioning, the provisioning is handled by a PL/SQL plug-in and not by any component of Oracle Identity Management

The Oracle Directory Integration Platform propagates PL/SQL events to a provisioning-integrated application, which then runs a PL/SQL plug-in to process the events. Execution of a PL/SQL plug-in occurs within the application repository and not within the address space of any Oracle Identity Management component. Because provisioning is handled by a PL/SQL plug-in and not by any component of Oracle Identity Management, provisioning-integrated applications that implement a PL/SQL plug-in are provisioned asynchronously.

Asynchronous provisioning with the Oracle Directory Integration Platform Provisioning Service can be invoked from Oracle Identity Management Tools (such as Provisioning Console and bulkprov), synchronization with third-party directories, or command-line LDAP tools.

Asynchronous provisioning from Oracle Identity Management Tools such as the Provisioning Console, bulk provisioning with the provProfileBulkProv command, and third-party directories follows this process:

  1. A new user entry and an associated entry containing application-specific user preferences are created in Oracle Internet Directory.

  2. At the next scheduled synchronization interval, the Oracle Directory Integration Platform identifies new user entries in Oracle Internet Directory that require provisioning.

  3. Provisioning events are sent from the Oracle Directory Integration Platform to the PL/SQL plug-in.

Asynchronous provisioning using command line LDAP tools follows this process:

  1. A new user entry is created in Oracle Internet Directory using a command-line LDAP tool.

  2. At the next scheduled synchronization interval, the Oracle Directory Integration Platform identifies new user entries in Oracle Internet Directory that require provisioning, and creates an associated entry containing application-specific user preferences.

  3. Provisioning events are sent from the Oracle Directory Integration Platform to the PL/SQL plug-in.

Provisioning Data Flow

Regardless of whether it is provisioned synchronously or asynchronously, an application can invoke the Pre-Data Entry and Post-Data Entry plug-ins to enhance provisioning intelligence and implement business policies. Both plug-ins are invoked by Oracle Identity Management components such as the Oracle Internet Directory Provisioning Console and bulk provisioning with the provProfileBulkProv command.

The Pre-Data Entry plug-in populates fields according to provisioning policies. The primary purpose of this plug-in is to determine whether a user should be provisioned in an application. For example, if an organization has a a policy where only managers are provisioned for a financial application, the Pre-Data Entry plug-in can be used to identify which user entries to provision. Common user attributes are already populated when this plug-in is invoked, so it should have adequate information to make provisioning decisions.

The Post-Data Entry plug-in primarily validates data entered by users for common attributes and application-specific attributes. The validation for the plug-in must be successful for provisioning to continue.

The provisioning data flow follow this process:

  1. Base user information is created.

  2. The Pre-Data Entry plug-in is invoked, which populates fields according to policies.

  3. The Post-Data Entry plug-in is invoked, which validates data entered by the user.

  4. Depending on the provisioning approach, either asynchronous or synchronous provisioning procedures are invoked.

If provisioning is performed with the Provisioning Console, then after the Pre-Data Entry Plug-in is invoked, but before the Post-Data Entry plug-in is invoked, an administrator can modify the application attributes.

8.6.1.1.4 Configuration Artifacts

Oracle Directory Integration Platform-related configuration details are maintained in the dip-config.xml file. This configuration file is packaged as part of the Oracle Directory Integration Platform application. The default location for the dip-config.xml file is:

MW_HOME/user_projects/domains/domainName/config/
fmwconfig/servers/serverName/applications/DIP_11.1.1.2.0/configuration

Where domainName is the name of your domain serverName is the name of your managed server.

Config MBeans manages parameters. Table 8-8 shows the configuration parameters required in dip-config.xml to start the Oracle Directory Integration Platform:

Table 8-8 Configuration Parameters Required to Start Directory Integration Platform

Parameter Description

OID Host

Host name of the Oracle Internet Directory to which Oracle Directory Integration Platform needs to connect.

OID Port

The Oracle Internet Directory port

SSL Mode

The SSL mode used to connect to Oracle Internet Directory. Valid values are:

  • 0: non-SSL

  • 1: SSL with no authentication (handshake only). This is the default mode

  • 2: SSL with server-only authentication enabled. Authentication is based on the Trust Point Certificate.

JKS Location

File system location to store the Java Keystore (JKS)

Quartz Threads

Maximum number of threads that can be used by Quartz for scheduling the processes.

After the Oracle Directory Integration Platform server is up and running, it reads details from Oracle Internet Directory for handling its synchronization and provisioning functions.

For information on creating synchronization profiles and provisioning profiles, see:

8.6.1.1.5 External Dependencies

Oracle Directory Integration Platform uses an Oracle Internet Directory to store its metadata. The Quartz Scheduler uses the ODSSM schema to store its scheduling information in the database. The same database is used by Oracle Internet Directory and Oracle Directory Integration Platform. The ODSSM schema required for Oracle Directory Integration Platform is created as part of Oracle Internet Directory schema creation.

Oracle Directory Integration Platform is also dependent on the Oracle Credential Store Framework (CSF), a secure framework provided by Oracle and the Java Keystore (JKS) to store wallets and credentials used to connect to Oracle Internet Directory and third party LDAP stores over SSL.

Oracle Directory Integration Platform is also dependent on the Oracle Fusion Middleware Common Audit Framework, which is installed by default.

8.6.1.1.6 Oracle Directory Integration Platform Log File

Oracle Directory Integration Platform is a J2EE application deployed on top of WebLogic Server. All log messages are logged in the server log file of the WebLogic Server that the application is deployed on. The default location of the server log is:

WEBLOGIC_SERVER_HOME/user_projects/domains/domainName/servers/serverName/logs/
serverName-diagnostic.log

8.6.2 Oracle Directory Integration Platform High Availability Concepts

This section provides conceptual information about using Oracle Directory Integration Platform in a high availability configuration.

In the Oracle Directory Integration Platform high availability configuration described in this section, Oracle Directory Integration Platform and Oracle Directory Services Manager are installed and configured on two hosts in a two-node high availability active-active configuration.

8.6.2.1 Oracle Directory Integration Platform High Availability Architecture

Figure 8-9 shows the Oracle Directory Integration Platform and Oracle Directory Services Manager high availability architecture in an active-active configuration.

Figure 8-9 Oracle Directory Integration Platform and Oracle Directory Services Manager in a High Availability Architecture

Description of Figure 8-9 follows
Description of "Figure 8-9 Oracle Directory Integration Platform and Oracle Directory Services Manager in a High Availability Architecture"

In Figure 8-9, the application tier includes the IDMHOST1 and IDMHOST2 computers.

On IDMHOST1, the following installations have been performed:

  • An Oracle Directory Integration Platform instance and Oracle Directory Services Manager instance have been installed on the WLS_ODS1 Managed Server. The Oracle RAC database has been configured in a JDBC multi data source to protect the instances from Oracle RAC node failure.

  • A WebLogic Administration Server has been installed. Under normal operations, this is the active Administration Server.

On IDMHOST2, the following installations have been performed:

  • An Oracle Directory Integration Platform instance and Oracle Directory Services Manager instance have been installed in the WLS_ODS2 Managed Server. The Oracle RAC database has been configured in a JDBC multi data source to protect the instances from Oracle RAC node failure.

    The instances in the WLS_ODS2 Managed Server on IDMHOST2 and the instances in the WLS_ODS1 Managed Server on IDMHOST1 are configured as the CLUSTER_ODS cluster.

  • A WebLogic Administration Server has been installed. Under normal operations, this is the passive Administration Server. You will make this Administration Server active if the Administration Server on IDMHOST1 becomes unavailable.

8.6.2.1.1 Starting and Stopping the Cluster

In a high availability architecture, Oracle Directory Integration Platform and Oracle Directory Services Manager are deployed on an Oracle WebLogic Cluster that has at least two servers as a part of the cluster.

By default, the WebLogic Server starts, stops and monitors the applications. By default, both the Oracle Directory Integration Platform and Oracle Directory Services Manager applications leverage the high availability features of the underlying WebLogic Clusters. In case of hardware or other failures, session state is available to other cluster nodes that can resume the work of the failed node.

In a high availability environment, WebLogic Node Manager is configured to monitor the WebLogic servers. In case of failure, Node Manager restarts the WebLogic Server. If Node Manager cannot restart the server, then the front-ending load balancing router detects failure of a WebLogic instance in the Cluster and routes traffic to surviving instances.

8.6.2.1.2 Cluster-Wide Configuration Changes

When Oracle Internet Directory is deployed in an active-active high availability configuration, all the Oracle Internet Directory instances belonging to the cluster share the same database. Any changes made to Oracle Directory Integration Platform on one Oracle Internet Directory node would automatically be propagated to all the Oracle Internet Directory instances in the cluster.

The following subsections describe configuration changes made to the Oracle Directory Integration Platform application in an Oracle Internet Directory deployment. In a multimaster replication deployment, configuration changes need to be applied to all the nodes in the cluster manually, as described below.

Directory Integration Profiles

Changes made to directory integration profiles on one Oracle Internet Directory node are not automatically replicated to other Oracle Internet Directory nodes in a default multimaster Oracle Internet Directory replication environment. They need to be manually copied over from the primary node to the secondary nodes on a periodic basis. This enables a directory synchronization profile to run on a secondary node if a problem occurs on the primary node.

One of the parameters used by Oracle Directory Integration Platform is orcllastappliedchangenumber. The value assigned to the lastchangenumber attribute in a directory synchronization profile depends on the directory server on which Oracle Directory Integration Platform is running. In an active-active Oracle Directory Integration Platform configuration, you must manually update the lastchangenumber attribute in all instances.

The next section details the steps to copy the synchronization profiles and the provisioning profiles from the primary Oracle Internet Directory to the secondary Oracle Internet Directory in a multimaster replication deployment.

Directory Synchronization Profiles

After you copy an export profile to a target node, you must update the lastchangenumber attribute with the target node value. To update the value:

  1. Disable the synchronization profile.

  2. Get the value of the lastchangenumber attribute on the target node using the ldapsearch command.

  3. Use ldapsearch to get the LDIF dump of the profile entry.

  4. Use ldapadd to add the profile to the other Oracle Internet Directory instance.

  5. Use the updatechgnum operation of the manageSyncProfiles command to update the lastchangenumber attribute in the export profile you copied to the target node with the value you obtained in Step 2.

  6. Enable the synchronization profile.

Directory Provisioning Profiles

In a default multimaster Oracle Internet Directory replication environment, the Oracle Directory Integration Platform is installed in the same location as the primary Oracle Internet Directory. The information and steps in this section are applicable only when multimaster replication is set up.

If the primary node fails, event propagation stops for all profiles located on the node. Although the events are queued and not lost while the primary node is stopped, the events will not be propagated to any applications that expect them. To ensure that events continue to be propagated even when the primary node is down for the Version 1.0 and 2.0 profiles, the directory provisioning profiles must be copied to other secondary nodes.

However, directory provisioning profiles should only be copied from the primary node to any secondary nodes immediately after an application is installed and before any user changes are made in Oracle Internet Directory.

To synchronize the directory provisioning profiles between a primary node and any secondary nodes, you must do the following:

  1. On the primary node, use the ldifwrite command to create an LDIF dump of the entries from this container:

    cn=provisioning profiles,cn=changelog subscriber,cn=oracle internet directory

  2. Copy the LDIF dump to the secondary node.

  3. Use the ldapadd command to add the profiles on the secondary node.

8.6.2.2 Protection from Failures and Expected Behavior

This section describes protection from different types of failure in an Oracle Directory Integration Platform active-active cluster.

8.6.2.2.1 Process Failure

In a high availability environment, the Oracle Directory Integration Platform application is deployed on an WebLogic Server cluster comprised of at least two WebLogic instances.

By default, the Oracle Directory Integration Platform application leverages the high availability features of the underlying WebLogic Clusters. When Oracle Directory Integration Platform is deployed, the Quartz scheduler is started with a clustering option. When started with the clustering option, depending on the load on the node, the scheduler runs the job on any of the available nodes in the cluster. In case of hardware or other failures on one or more nodes, the scheduler runs the jobs on the available nodes.

In addition, in a high availability environment, WebLogic Node Manager is configured to monitor the WebLogic servers. In case of failure, Node Manager restarts the WebLogic Server.

Within the Oracle Directory Integration Platform application, the Quartz Scheduler invokes the Provisioning or Synchronization EJBs that do the actual work. As soon as the Quartz scheduler invokes an EJB, it tags that EJB as running the job. In case the EJB fails, the Quartz scheduler marks the job as failed and reschedules it to run later by another EJB.

8.6.2.2.2 Expected Client Application Behavior When Failure Occurs

Oracle Directory Integration Platform failover is not transparent to end users.

Configuration changes made on a Oracle Directory Integration Platform instance deployed in a high availability topology are not propagated automatically to all the Oracle Directory Integration Platform instances in the topology.

Oracle recommends that you use the manageDIPServerConfig tool to make the same configuration changes on all Oracle Directory Integration Platform instances in the topology. This ensures that the configuration across all the Oracle Directory Integration Platform instances in the topology is uniform.

See Oracle Fusion Middleware Administrator's Guide for Oracle Directory Integration Platform for more information about the manageDIPServerConfig tool.

8.6.2.2.3 External Dependency Failure

Oracle Directory Integration Platform requires the back-end repository, Oracle Internet Directory, Credential Store Framework and the WebLogic Managed Server to be available during startup. Oracle Directory Integration Platform fails to start if any of these is not available.

8.6.2.3 Oracle Directory Integration Platform Prerequisites

This section describes prerequisites for setting up Oracle Directory Integration Platform in the high availability architecture.

Note:

Oracle Directory Integration Platform uses Quartz to maintain its jobs and schedules in the database. For the Quartz jobs to be run on multiple Oracle Directory Integration Platform nodes in a cluster, it is required that the system clocks on the cluster nodes be synchronized.

Oracle Internet Directory should be installed and configured by following the instructions in these sections:

8.6.3 Oracle Directory Integration Platform High Availability Configuration Steps

In a high availability environment, it is recommended that WebLogic Server utilities be used for clustering, load balancing, and failover of Oracle Directory Integration Platform instances and Oracle Directory Services Manager.

This section describes how to perform the following installation and configuration on IDMHOST1 and IDMHOST2:

It is not required to install Oracle Directory Integration Platform and Oracle Directory Services Manager in the same installation session, on the same Managed Server, or on the same host. The installation and configuration steps in this section are one example of installing Oracle Directory Integration Platform and Oracle Directory Services Manager in a two-node active-active cluster.

8.6.3.1 Configuring Oracle Directory Integration Platform on IDMHOST1

Follow these steps to configure Oracle Directory Integration Platform and Oracle Directory Services Manager on IDMHOST1:

  1. Ensure that the system, patch, kernel and other requirements are met. These are listed in Oracle Fusion Middleware Installation Guide for Oracle Identity Management in the Oracle Fusion Middleware documentation library for the version you are using.

  2. Ensure that Oracle Identity Management software has been installed and upgraded on IDMHOST1 as described in Section 8.3.3.1, "Installing Oracle Fusion Middleware Components."

  3. Ensure that port 7006 is not in use by any service on IDMHOST1 by issuing these commands for the operating system you are using. If a port is not in use, no output is returned from the command.

    netstat -an | grep LISTEN | grep ":7006"

  4. If the port is in use (if the command returns output identifying the port), you must free the port.

    Remove the entries for port 7006 in the /etc/services file and restart the services, or restart the computer.

  5. Copy the staticports.ini file from the Disk1/stage/Response directory to a temporary directory.

  6. Edit the staticports.ini file that you copied to the temporary directory to assign the following custom ports (uncomment the line where you specify the port numbers for Oracle Directory Services Manager):

    # The port for ODSM server port
ODS Server Port No = 7006

  7. Start the Oracle Identity Management 11g Configuration Wizard located under the ORACLE_HOME/bin directory as follows:

    ./config.sh

  8. On the Welcome screen, click Next.

  9. On the Select Domain screen, select Create New Domain and enter the domain details:

    • User Name: weblogic

    • User Password: ******

    • Confirm Password: ******

    • Domain Name: IDMDomain

    Click Next.

  10. On the Specify Installation Location screen, specify the following values:

    • Oracle Middleware Home Location: This value is prefilled and cannot be changed.

    • Oracle Home Directory: This value is prefilled and cannot be changed)

      ods

    • WebLogic Server Directory:

      /u01/app/oracle/product/fmw/wlserver_10.3

    • Oracle Instance Location:

      /u01/app/oracle/admin/ods_instance1

    • Oracle Instance Name:

      ods_instance1

    Click Next.

  11. On the Specify Oracle Configuration Manager Details screen, specify these values:

    • Email Address: Provide the email address for your My Oracle Support account.

    • Oracle Support Password: Provide the password for your My Oracle Support account.

    • Check the checkbox next to the I wish to receive security updates via My Oracle Support field.

    Click Next.

  12. On the Configure Components screen, select Oracle Directory Integration Platform, Management Components - Oracle Directory Services Manager. Deselect all the other components. Ignore the warning that says Oracle Internet Directory needs to be configured as a prerequisite.

    Select the Clustered check box.

    Click Next.

    Note:

    The default WebLogic Server clustering mode set by the installer is unicast (not multicast).

  13. On the Configure Ports screen, select Specify Ports Using Configuration File and enter the filename for the staticports.ini file that you copied to the temporary directory.

    Click Next.

  14. On the Specify OID Details screen, specify the following:

    • Hostname: oid.example.com

    • Port: 636

    • Username: cn=orcladmin

    • Password: ******

    Click Next.

  15. On the Specify Schema Database screen, select Use Existing Schema and specify the following values:

    • Connect String:

      infradbhost1-vip.example.com:1521:oiddb1^infradbhost2-vip.example.com:1521:oiddb2@oid.example.com

      Note:

      The Oracle RAC database connect string information needs to be provided in the format host1:port1:instance1^host2:port2:instance2@servicename.

      During this installation, it is not required for all the Oracle RAC instances to be up. If one Oracle RAC instance is up, the installation can proceed.

      It is required that the information provided above is complete and accurate. Specifically, the correct host, port, and instance name must be provided for each Oracle RAC instance, and the service name provided must be configured for all the specified Oracle RAC instances.

      Any incorrect information entered in the Oracle RAC database connect string has to be corrected manually after the installation.

    • User Name: ODSSM

    • Password: ******

    Click Next.

  16. On the Installation Summary screen, review the selections to ensure that they are correct (if they are not, click Back to modify selections on previous screens), and click Install.

  17. On the Installation Progress screen on UNIX systems, a dialog box appears that prompts you to run the oracleRoot.sh script. Open a window and run the script, following the prompts in the window.

    Click Next.

  18. On the Configuration screen, multiple configuration assistants are launched in succession; this process can be lengthy. When it completes, click Next.

  19. On the Installation Complete screen, click Finish to confirm your choice to exit.

8.6.3.2 Configuring Oracle Directory Integration Platform and Oracle Directory Services Manager on IDMHOST2

To configure Oracle Directory Integration Platform and Oracle Directory Services Manager on IDMHOST2:

  1. Ensure that the system, patch, kernel and other requirements are met. These are listed in Oracle Fusion Middleware Installation Guide for Oracle Identity Management in the Oracle Fusion Middleware documentation library for the version you are using.

  2. Ensure that Oracle Identity Management software has been installed and upgraded on IDMHOST2 as described in Section 8.3.3.1, "Installing Oracle Fusion Middleware Components."

  3. Start the Oracle Identity Management 11g Configuration Wizard located under the ORACLE_HOME/bin directory as follows:

    ./config.sh

  4. On the Welcome screen, click Next.

  5. On the Select Installation Type screen, select Install & Configure then click Next.

  6. On the Prerequisite Checks screen, the installer completes the prerequisite check. If any fail, please fix them and restart your installation.

    Click Next.

  7. On the Select Domain screen, select the Expand Cluster option and specify the values shown in the example below:

    • HostName: idmhost1.example.com

    • Port: 7001

    • UserName: weblogic

    • User Password: <password for the weblogic user>

    Click Next.

    Note:

    Oracle WebLogic Administration Server runs on IDMHOST1.

  8. On the Specify Installation Location screen, specify the following values:

    • Oracle Middleware Home Location: Prefilled and cannot be changed.

      /u01/app/oracle/product/fmw

    • Oracle Home Directory: Prefilled and cannot be changed.

      ods

    • WebLogic Server Directory:

      /u01/app/oracle/product/fmw/wlserver_10.3

    • Oracle Instance Location:

      /u01/app/oracle/admin/ods_instance2

    • Oracle Instance Name:

      ods_instance2

    Click Next.

  9. On the Configure Components screen, de-select all products except Oracle DIP and Management Components.

    Click Next.

  10. On the Configure Ports screen, select Specify Ports Using Configuration File and enter the full pathname to the staticports.ini file that you edited in the temporary directory.

    Click Next.

  11. On the Installation Summary screen, review the choices you made. If you must make any changes, click Back. If you made the correct selections, click Install.

  12. On the Installation Progress screen, view the progress of the installation.

  13. On UNIX systems, once the installation is done, the oracleRoot.sh confirmation dialog box opens. It explains that a configuration script needs to be run as root before the installation can proceed.

    Leave the confirmation dialog box open, open another shell window, log in as root, and run this script file:

    /u01/app/oracle/product/fmw/ods/oracleRoot.sh

  14. On the Configuration Progress screen, view the progress of the configuration.

  15. On the Installation Complete screen, click Finish to confirm your choice to exit.

8.6.3.3 Post-Installation Steps for Oracle Directory Integration Platform and Oracle Directory Services Manager

In the previous section, the installer created a second Managed Server, wls_ods2 on IDMHOST2. However, the Oracle Directory Integration Platform application is not deployed on IDMHOST2 and the newly created Managed Server is not automatically started. Also, the WebLogic Administration Console shows the state of the wls_ods2 Managed Server on IDMHOST2 as UNKNOWN.

Follow the post-installation steps in this section to complete the installation and configuration of the Oracle Directory Integration Platform and Oracle Directory Services Manager applications on IDMHOST2.

8.6.3.3.1 Copy the Oracle Directory Integration Platform Configuration from IDMHOST1 to IDMHOST2

To copy the Oracle Directory Integration Platform directly application from IDMHOST1 to IDMHOST2:

Copy the following directory on IDMHOST1: MW_HOME/user_projects/domains/IDMDomain/config/fmwconfig/servers/wls_ods1/applications to the following location on IDMHOST2: MW_HOME/user_projects/domains/IDMDomain/config/fmwconfig/servers/wls_ ods2.

For example, from IDMHOST1, run the following command:

scp -rp MW_HOME/user_projects/domains/IDMDomain/config/fmwconfig/servers/wls_ods1/applications/odsm user@IDMHOST2:/MW_HOME/user_projects/domains/IDMDomain/config/fmwconfig/servers/wls_ods2
8.6.3.3.2 Restart the Managed Server on IDMHOST2 in a Cluster

To restart the newly-created wls_ods2 Managed Server in a cluster on IDMHOST2:

  1. Use this URL to access the Administration Console:

    http://idmhost1.example.com:7001/console

    Log into the console using the administrator's credentials.

  2. In the left pane, expand Environment and select Clusters.

    See the "Starting and Stopping Oracle Fusion Middleware" chapter of the Oracle Fusion Middleware Administrator's Guide for information on starting and stopping WebLogic Servers.

  3. Click on the link for the cluster (cluster_ods) containing the Managed Server (wls_ods2) you want to stop.

  4. Select Control.

  5. Under Managed Server Instances in this Cluster, select the check box next to the Managed Server (wls_ods2) you want to start and click Start.

  6. On the Cluster Life Cycle Assistant page, click Yes to confirm.

  7. Node Manager starts the server on the target machine. When the Node Manager finishes its start sequence, the server's state is indicated in the State column in the Servers status table. The state should be RUNNING.

8.6.3.4 Installing Oracle Fusion Middleware Components on WEBHOST1 and WEBHOST2

This section describes how to install the required binaries for the Oracle Home (ORACLE_HOME) for Oracle HTTP Server.

Oracle strongly recommends that you read the release notes for any additional installation and deployment considerations prior to starting the setup process.

8.6.3.4.1 Installing Oracle HTTP Server for the Web Tier

This section describes how to install Oracle HTTP Server.

Ensure that the system, patch, kernel and other requirements are met. These are listed in the Oracle Fusion Middleware Installation Guide for Oracle Web Tier in the Oracle Fusion Middleware documentation library for the version you are using.

If the /etc/oraInst.loc file exists, verify that its contents are correct. Specifically, check that the inventory directory is correct and that you have write permissions for that directory. If the /etc/oraInst.loc file does not exist, you can skip this step.

Start the installer for Oracle Web Tier components.

HOST1> ./runInstaller

Then run these installation steps:

  1. On the Prerequisite Checks screen, verify that the checks complete successfully, then click Next.

  2. On the Specify Installation Location screen, enter the following values:

    MW_HOME: Enter the value of the MW_HOME, for example:

    /u01/app/product/fmw

    Select the previously installed Middleware Home from the drop-down list. For the Oracle HTTP Server Oracle Home (OHS_ORACLE_HOME) directory, enter the directory name WEB.

    Click Next.

  3. On the Summary screen, click Install.

    When prompted, run the script oracleRoot.sh as the root user.

  4. On the Installation Complete screen, click Finish.

8.6.3.4.2 Upgrading the Oracle HTTP Server Oracle Home to Patch Set 3

To upgrade your Oracle HTTP Server software to 11.1.1.4 (Patch Set 3):

  1. Start the Web Tier Upgrade Installer by running ./runinstaller.

  2. On the Welcome screen, click Next.

  3. On the Prerequisite Checks screen, click Next.

  4. On the Specify Install Location screen, provide the path to the Oracle Middleware Home and the name of the Oracle HTTP Server Oracle Home directory.

  5. On the Installation Summary screen, validate your selections and then click Install. After installation is complete, the oracleRoot.sh confirmation dialog box opens. This dialog box advises you that a configuration script needs to be run as root before the installation can proceed.

  6. Leave the confirmation dialog box open, open another shell window, log in as root, and run the script file: /u01/app/oracle/product/fmw/id/oracleRoot.sh. After the script completes, click OK.

  7. On the Installation Complete screen, click Finish to exit.

8.6.4 Oracle Directory Integration Platform Failover and Expected Behavior

In a high availability environment, the Oracle Directory Integration Platform application is deployed on an WebLogic Server cluster that comprises at least two WebLogic instances.

By default, the Oracle Directory Integration Platform application leverages the high availability features of the underlying WebLogic clusters. In case of hardware or other failures, session state is available to other cluster nodes that can resume the work of the failed node.

In addition, in a high availability environment, WebLogic Node Manager is configured to monitor the WebLogic servers. In case of failure, Node Manager restarts the WebLogic Server. In case of a database instance failure, the surviving Oracle RAC node takes over any remaining processes. There may be innocuous errors in the Managed Servers logs during an Oracle RAC failover, as discussed in Section 8.6.5, "Troubleshooting Oracle Directory Integration Platform High Availability."

8.6.5 Troubleshooting Oracle Directory Integration Platform High Availability

This section describes how to troubleshoot issues involving Oracle Directory Integration Platform high availability. Topics in this section include the following:

8.6.5.1 Managed Server Log File Exceptions Received for Oracle Directory Integration Platform During an Oracle RAC Failover

During an Oracle RAC failover, exceptions similar to the ones below are seen in the Managed Server log files running the Oracle Directory Integration Platform application. These errors are thrown when the multi data sources configured on the WebLogic Server platform try to verify the health of the Oracle RAC database instances during failover. These are innocuous errors that you can ignore. The Oracle Directory Integration Platform application will recover and begin to operate normally after a lag of one or two minutes. During an Oracle RAC failover, there will be no Oracle Directory Integration Platform down time if one Oracle RAC instance is running at all times.

RuntimeException:
[2008-11-21T00:11:10.915-08:00] [wls_ods] [ERROR] []
[org.quartz.impl.jdbcjobstore.JobStoreTX] [tid: 25] [userId: <anonymous>]
[ecid: 0000Hqy69UiFW7V6u3FCEH199aj0000009,0] [APP: DIP] ClusterManager: Error
managing cluster: Failed to obtain DB connection from data source
'schedulerDS': java.sql.SQLException: Could not retrieve datasource via JNDI
url 'jdbc/schedulerDS' java.sql.SQLException: Cannot obtain connection:
driverURL = jdbc:weblogic:pool:schedulerDS, props =
{EmulateTwoPhaseCommit=false, connectionPoolID=schedulerDS,
jdbcTxDataSource=true, LoggingLastResource=false,
dataSourceName=schedulerDS}.[[
Nested Exception: java.lang.RuntimeException: Failed to setAutoCommit to true
for pool connection

AuthenticationException while connecting to OID:
[2008-11-21T00:12:08.812-08:00] [wls_ods] [ERROR] [DIP-10581] [oracle.dip]
[tid: 11] [userId: <anonymous>] [ecid: 0000Hqy6m54FW7V6u3FCEH199apO000000,0]
[APP: DIP] DIP was not able to get the context with the given details {0}[[
javax.naming.AuthenticationException: [LDAP: error code 49 - Invalid
Credentials]

Most of the exceptions will be related to the scheduler or LDAP, for example:

1. Could not retrieve datasource via JNDI url 'jdbc/schedulerDS' java.sql.SQLException.

2. javax.naming.AuthenticationException: [LDAP: error code 49 - Invalid Credentials]

8.6.5.2 Error Messages Received After Starting WebLogic Node Manager

If you see the following error message after starting WebLogic Node Manager, follow the steps that appear below after the error message:

<Dec 15, 2008 8:40:05 PM> <Warning> <Uncaught exception in server handler:
javax.net.ssl.SSLKeyException: [Security:090482]BAD_CERTIFICATE alert was
received from stbee21.example.com - 152.68.64.2155. Check the peer to 
determine why it rejected the certificate chain (trusted CA configuration,
hostname verification). SSL debug tracing may be required to determine the
exact reason the certificate was rejected.> javax.net.ssl.SSLKeyException:
[Security:090482]BAD_CERTIFICATE alert was received from stbee21.example.com -
152.68.64.215. Check the peer to determine why it rejected the certificate chain 
(trusted CA configuration, hostname verification). SSL debug tracing may be
required to determine the exact reason the certificate was rejected.

  1. If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit.

  2. In the left pane of the Console, expand Servers and AdminServer (admin).

  3. Select the Configuration > SSL > Advanced Link.

  4. Select None for Hostname Verification.

  5. Click Save to save the setting.

  6. To activate these changes, in the Change Center of the Administration Console, click Activate Changes.

  7. Restart all servers.

If the Managed Server is started in Admin mode, perform these steps:

  1. If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit.

  2. In the left pane of the Console, expand Servers and the name of the server that is running in ADMIN mode.

  3. Select the Control > Start/Stop tab.

  4. Select the name of the server.

  5. Click Resume.

  6. Select Yes to resume servers.

8.6.5.3 If WebLogic Node Manager Fails to Start

If WebLogic Node Manager fails to start, ensure that you copied the following domains file from IDMHOST1 to IDMHOST2:

WL_HOME/common/nodemanager/nodemanager.domains

8.6.5.4 Configuration Changes Do Not Automatically Propagate to All Oracle Directory Integration Platform Instances in a Highly Available Topology

When you change the configuration of an Oracle Directory Integration Platform instance in a high availability topology, the configuration change does not propagate automatically to all the Oracle Directory Integration Platform instances in the topology.

Use the manageDIPServerConfig tool to make the same configuration change for each Oracle Directory Integration Platform instance in the topology. The tool ensures the same configuration across all the Oracle Directory Integration Platform instances in the topology. See Oracle Fusion Middleware Administrator's Guide for Oracle Directory Integration Platform for more information about the manageDIPServerConfig tool.

8.6.5.5 Operation Cannot Be Completed for Unknown Errors Message

The following error message may appear intermittently when you use the manageSyncProfiles command:

OPERATION CANNOT BE COMPLETED FOR UNKNOWN ERRORS

To resolve this issue, start and stop the Managed Server (wls_ods1 or wls_ods2). If the problem persists, repeat the copy method on the second node.

8.7 Starting and Stopping Components

To start and stop components, see the procedure Starting and Stopping Components in the Oracle Fusion Middleware Administrator's Guide.