8 Configuring High Availability for Identity Management Components

This chapter describes configuring Identity Management products for high availability in an active-active configuration.

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. This architecture includes a web tier, application tier, and directory tier.

Figure 8-1 Oracle Fusion Middleware 11g Oracle Identity Management High Availability Architecture

Description of Figure 8-1 follows
Description of "Figure 8-1 Oracle Fusion Middleware 11g Oracle Identity Management High Availability Architecture"

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

Separate Oracle HTTP Server instances are installed on WEBHOST1 and on WEBHOST2. A load balancing router routes requests to Oracle HTTP Server instances on WEBHOST1 and WEBHOST2.

The application tier includes IDMHOST1 and IDMHOST2 computers.

On IDMHOST1, the following installations have been performed:

  • An Oracle Directory Services Manager instance and an ODIP instance are installed in the WLS_ODS1 Managed Server. Quartz Scheduler contacts Oracle RAC database through a JDBC multi data source to protect the instances from Oracle RAC node failures.

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

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

On IDMHOST2, the following installations have been performed:

  • An Oracle Directory Services Manager instance and an ODIP instance are installed in the WLS_ODS2 Managed Server. The Oracle RAC database is configured in a JDBC multi data source to protect 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 information about active-passive configurations. The Oracle Access Manager Console is also installed as a singleton application and is passive until the Administration Server on IDMHOST2 becomes active.

The directory tier includes OIDHOST1 and OIDHOST2. On both, an Oracle Internet Directory instance and an Oracle Virtual Directory instance are 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.

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.1.1 About the 11g Oracle Identity Management Products

Table 8-1 summarizes Oracle Identity Management products that you can install using the suite-level installation program for 11g. See the introductory chapter of the Oracle Fusion Middleware Quick Installation Guide for Oracle Identity Management for details:

Table 8-1  The 11g Identity Management Components and Product Suites

Product Description Product Suite

Oracle Internet Directory

LDAP Version 3-enabled service that enables fast retrieval and centralized management of information about dispersed users, network configuration, and other resources.

Oracle Identity Management Platform and Directory Services Suite

Oracle Virtual Directory

LDAP Version 3-enabled service. Provides an abstracted view of one or more enterprise data sources.

Oracle Virtual Directory consolidates multiple data sources into a single directory view, enabling you to integrate LDAP-aware applications with diverse directory server data stores.

Oracle Identity Management Platform and Directory Services Suite

Oracle Directory Integration Platform

The ODIP is a J2EE application that enables you to synchronize data between various directories and the back-end directory. ODIP includes services and interfaces that enable you to deploy synchronization solutions with other enterprise repositories.

Oracle Identity Management Platform and Directory Services Suite

Oracle Directory Services Manager

GUI for Oracle Virtual Directory and Oracle Internet Directory. Oracle Directory Services Manager that simplifies administration and configuration of Oracle Virtual Directory and Oracle Internet Directory by enabling you to use web-based forms and templates.

Oracle Directory Services Manager is available from either the Oracle Enterprise Manager Fusion Middleware Control or from its own URL.

Oracle Identity Management Platform and Directory Services Suite

Oracle Access Manager

Oracle Access Manager 11g provides a single authoritative source for all authentication and authorization services. The core service provided is the checking of valid session tokens, the requesting of credentials if the session token is invalid or missing, and the issuing of session tokens, intercepting resource requests and evaluating access control policies to control access to resources.

Oracle Identity and Access Management Suite

Oracle Identity Manager

Oracle Identity Manager is a user provisioning and administration solution that automates the process of adding, updating, and deleting user accounts from applications and directories. It also improves regulatory compliance by providing granular reports that attest to who has access to what. Oracle Identity Manager is available as a stand-alone product or as part of Oracle Identity and Access Management Suite.

Oracle Identity and Access Management Suite

Authorization Policy Manager

Authorization Policy Manager is a graphical interface tool for administering application policies. The intended users of Authorization Policy Manager are security administrators. With this tool, an administrator can view and manage policies across enterprise applications. Administrators can be specified to manage all applications running in the domain or just a subset of them.

Oracle Identity and Access Management Suite

Oracle Identity Navigator

Oracle Identity Navigator is an administrative portal designed to act as a launch pad for Oracle Identity Management products. It does not replace the individual product consoles. Rather, it enables you to access the Oracle Identity Management consoles from one site.

Oracle Identity and Access Management Suite

Oracle Adaptive Access Manager

Oracle Adaptive Access Manager (OAAM) is Oracle Identity Management's solution for web access real-time fraud detection and multifactor online authentication security for the enterprise. OAAM enables real-time blocking of fraudulent access requests, delivers advanced alerting mechanisms, and protects businesses and their customers from attacks such as phishing, Trojans, viruses, fraudulent transactions, and Man-in-the-Middle attacks.

Oracle Identity and Access Management Suite

Oracle Identity Federation

Oracle Identity Federation enables companies to provide services and share identities across their respective security domains, while providing protection from unauthorized access.

Oracle Identity Management Platform and Directory Services Suite


8.2 Prerequisites for Oracle Identity Management High Availability Configuration

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

This section includes the following topics:

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 the presence of 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 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 in its own Oracle Home and have two disk groups:

  • One for the Database files.

  • One for the Flash Recovery Area.

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

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

Oracle Real Application Clusters

Many Oracle Fusion Middleware components require that schemas are in a database prior to installation. Use the Repository Creation Utility (RCU) to create the component schemas in an existing database. For high availability environments, you must create the schemas and load them into an Oracle RAC database.

See Section 8.2.4, "Obtaining the Repository Creation Utility Software" to use RCU to load 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 11gR1 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. This guide refers to the directory as RCU_HOME.

Note:

On Windows operating systems, do not unzip the RCU .zip file to a directory name containing spaces.

Before you install any Oracle Identity Management components described in this chapter, run RCU to create the schemas used by the component into an Oracle RAC database. These schemas are required for the high availability Oracle Identity Management configurations described in this chapter.

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

8.2.4.1 Running the Repository Creation Utility

Use the Repository Creation Utility (RCU) that is version compatible with the product you are installing.

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

The schemas you create depend on the Identity Management products you wish to install and configure, for example:

  • If the database is for Oracle Identity Manager, select Identity Management - Oracle Identity Manager.

    Note:

    the SOA and the MDS Schemas are automatically selected.

  • If the database is for Oracle Internet Directory, select Identity Management - (Oracle Internet Directory - ODS).

  • If the database is for Oracle Access Manager, select Identity Management - Oracle Access Manager.

  • If the database is for Oracle Identity Federation, select Identity Management - Oracle Identity Federation.

  • If the database is for Oracle Adaptive Access Manager, select Identity Management - Oracle Adaptive Access Manager.

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. This value is checked by the Repository Creation Utility.

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

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

One common way to change 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-2 shows values used for database configuration examples in this chapter.

Table 8-2 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 Access Manager

oam.example.com

oamdb1, oamdb2

Oracle Identity Manager

oim.example.com

oimdb1, oimdb2

Authorization Policy Manager

apm.example.com

apmdb1, apmdb2

Oracle Identity Navigator

N/A

N/A

Oracle Adaptive Access Manager

oaam.example.com

oaamdb1, oaamdb2

Oracle Identity Federation

oif.example.com

oifdb1, oifdb2


8.2.5.2 Database Services

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

You can also use SQL*Plus to configure your Oracle RAC database to automate failover for Oracle Internet Directory using the following instructions. Note that each of the following commands has to be run on only 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.

  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 on the SRVCTL command, see 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 go 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.

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 "Creating and Deleting Database Services with SRVCTL" in the Oracle Database Administrator's Guide for 11g Release 2 (11.2).

8.2.5.3 Verifying Transparent Application Failover

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

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. The hardware load balancer should have the following 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: The load balancer should have the ability to perform port translation, where it 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.

    This feature is recommended but not required.

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

    This feature is recommended but not required.

  • 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-3 shows the virtual server names to use for the external load balancer in the Oracle Identity Management high availability environment.

Table 8-3 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

Oracle Access Manager

sso.example.com

Oracle Adaptive Access Manager

oaam.example.com

Oracle Identity Manager

sso.example.com


8.2.5.4.2 Virtual Server Names

This section describes the virtual server names that should be set up for the high availability deployments described in this chapter.

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

oaam.example.com

This virtual server acts as the access point for all Oracle Adaptive Access Manager traffic that gets directed to the web site.

sso.example.com

This virtual server acts as the access point for all Oracle Access Manager traffic that gets directed to the web site.

This virtual server acts as the access point for all HTTP traffic that gets directed to the single sign on services.

This virtual host must be configured to preserve the client IP address for a request. In some load balancing routers, this can be achieved by enabling the load balancing router to insert the original client IP address of a request in an X-Forwarded-For HTTP header.

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.

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.

An Oracle Internet Directory node includes the following major elements:

Table 8-4 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 on Oracle Internet Directory replication, see Chapter 10, "Configuring Identity Management for Maximum High Availability.".

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

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 OID 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 1 (11.1.1), 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 (OID) process starts up, clients access OID using the LDAP or LDAPS protocol. There is no affect on other running instances when an OID 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 OID to take advantage of multiple processor systems.

The OID dispatcher process sends the LDAP connections to the OID 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 OID 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, see 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-5 shows Oracle Internet Directory processes and the log file name and location for the process.

Table 8-5 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 log files to troubleshoot Oracle Internet Directory, see Section 8.3.6, "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" to set up the two-node Cluster Configuration.

8.3.2.1 Oracle Internet Directory High Availability Architecture

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

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

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

Figure 8-2 shows Oracle Internet Directory (OID) 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 OID instances that are clustered on OIDHOST1 and OIDHOST2.

Transparent Application Failover (TAF) is used to connect the OID 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 5.1.7.1, "Oracle Internet Directory" for more information about using OID with Oracle RAC.

8.3.2.1.1 Starting and Stopping the Cluster

In the Cluster Configuration, OPMN commands start each OID instance. There is no affect on OID at startup. A new database connection spawns when OID starts.

When the cluster is stopped using OPMN, OID disconnects from the database and the OID 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 the nodes in the Cluster Configuration that share the same database read the same configuration information. The OIDMON process polls for configuration changes on each OID server and updates the database repository about configuration changes. OIDMON and other OID servers pull the changes from the database repository. In this way, any change made at a cluster member level is propagated to every OID server in the cluster.

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

cn=<component-name>,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 OID instances in a cluster are stored in the LDAP entry:

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

To retain instance-specific server configuration attributes for each OID instance in the cluster, choose a distinct OID component name for each OID 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 OID instance.

If you choose to have a common set of server configuration attributes for both OID instances in the cluster, then you should choose the same OID component name for both OID instances, for example, oid1 on both OID 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 OID LDAP server processes on a given node keep their caches in sync via semantics built around a shared memory segment managed by OID 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 OID database.

Oracle Internet Directory also caches metadata and metadata changes trigger notification across the nodes. The ldapmodify utility is used to change metadata. The OID server that gets the ldapmodify request for the metadata change notifies other OID 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 OID Cluster Configuration.

8.3.2.2.1 Oracle Internet Directory Process Failure

OIDMON monitors OID processes. If the OID process goes down, OIDMON tries to restart it.

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

If you cannot start an OID process, the front-ending load balancing router detects failure of OID 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 OID instance in the Cluster Configuration gets hung, the load balancing router detects this and routes requests to surviving instances.

If one OID instance 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 OID instance.

8.3.2.2.2 Expected Client Application Behavior When Failure Occurs

Oracle Internet Directory server failure is usually transparent to OID clients as they continue to get routed through the load balancer. External load balancers are typically configured to perform a health check of OID 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 OID instance and the request should be successful.

In OID 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 OID 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 OID from database failure.

By default, the tnsnames.ora file configured in OID's ORACLE_INSTANCE ensures that OID's connections to the database are load balanced between the Oracle RAC database instances. For example, if an OID 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, OID 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 TAF and high availability event notification are configured, 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 OID to reconnect to the database.

If none of the database instances are available for a prolonged period, then the OID 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 OID processes (LDAP and REPL) are automatically restarted by OIDMON.

While all database instances are down, OIDMON continues to be up and an opmnctl status command shows that OIDLDAPD instances are down. When a database instance becomes available, OIDMON restarts all configured OID instances.

All database failover induced activity for OID is recorded in the OIDMON log file.

8.3.2.3 Oracle Internet Directory Prerequisites

This section describes prerequisites for setting up the OID high availability architecture.

8.3.2.3.1 Synchronizing the Time on Oracle Internet Directory Nodes

Before setting up OID in a high availability environment, you must ensure that the time on the individual OID 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 OID 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 install the OID instances on OIDHOST1 and OIDHOST2, you must use the latest version of the Repository Creation Utility (RCU) to create the collection of schemas that Oracle Identity Management and Management Services uses.

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

To run RCU and create Identity Management schemas in a RAC database repository:

  1. Run this command:

    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 you deploy OID in a high availability configuration, Oracle recommends using an external load balancer to front-end OID instances and load balance requests between the OID instances. See 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.

Choose the standalone mode for deployments where OID is managed entirely using command line tools, and where Oracle Enterprise Manager Fusion Middleware Control and Oracle Directory Services Manager are not mandatory. Later, you can register standalone OID instances with a remote domain using opmnctl commands.

Oracle recommends that you set up OID in a clustered deployment in which clustered OID 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 Oracle 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.

8.3.3.1.1 Install Oracle WebLogic Server

The first step is to install Oracle WebLogic Server.

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

Ensure that system, patch, kernel and other requirements are met as Oracle Fusion Middleware Installation Guide for Oracle WebLogic Server describes.

Start the Oracle WebLogic Server installer then follow these steps:

  1. On the Welcome screen, click Next.

  2. On the Choose Middleware Home Directory screen, select Create a New Middleware Home. Choose a directory to install the software in.

    For the Middleware Home Directory, specify this value:

    /u01/app/oracleproduct/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.

On Linux platforms, 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 it. If the /etc/oraInst.loc file does not exist, skip this step.

Start the installer for Oracle Fusion Middleware components.

On UNIX, issue the command:

HOST1> runInstaller

On Windows, double-click setup.exe.

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 your home directory (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, on Linux and UNIX installations, 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

For more information on upgrading, 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 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 domain.

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 configure the Oracle Internet Directory instance on OIDHOST1:

  1. Ensure that the system, patch, kernel and other requirements are met. See Oracle Fusion Middleware Installation Guide for Oracle Identity Management.

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

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

    On UNIX:

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

    On Windows:

    netstat -an | findstr "LISTEN" | findstr ":389"
    
    netstat -an | findstr "LISTEN" | findstr ":636"
    
  4. If the port is in use (if the command returns output identifying the port), you must free the port.

    On UNIX:

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

    On Windows:

    Stop the component that is using the port.

  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 from the ORACLE_HOME/bin directory:

    On UNIX, issue this command: ./config.sh

    On Windows, double-click config.exe

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

  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^infradbhost2-vip.example.com:1521@oid.example.com
      

      Note:

      You must enter the Oracle RAC database connect string information in the short format host1:port1^host2:port2@servicename

      Do not enter the connect string in the long format, which includes instance names.

      Information you enter must be complete and accurate. You must enter the correct host and port for each Oracle RAC instance. The service name must be configured for all specified Oracle RAC instances.

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

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

    • User Name: ODS

    • Password: ******

    Click Next.

  15. On the Create Oracle Internet Directory screen, specify the Realm and enter the Administrator (cn=orcladmin) password and 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 launch in succession. When the process completes, click Next.

  19. On the Installation Complete screen, click Finish.

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

When you install OID using Oracle Identity Management 11g installer, the default component name that the installer assigns to the OID instance is oid1. You cannot change this component name.

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

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

The instance-specific configuration entry for the second OID 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 OID installation is performed on another computer and that instance uses the same database as the first two instances, the installer gives the third OID 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 OID instances is cn=dsaconfig, cn=configsets,cn=oracle internet directory. Any change in this entry will affect all the instances of OID.

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

8.3.3.2.3 Configuring Oracle Internet Directory on OIDHOST2

Ensure that the OID repository is running and then follow these steps to configure the OID instance on OIDHOST2:

Note:

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

  1. Ensure that the system, patch, kernel and other requirements are met. See Oracle Fusion Middleware Installation Guide for Oracle Identity Management.

  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 OID. The same ports should be used for the OID 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.

    On UNIX:

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

    On Windows:

    netstat -an | findstr "LISTEN" | findstr ":389"
    
    netstat -an | findstr "LISTEN" | findstr ":636"
    
  4. If the port is in use (if the command returns output identifying the port), you must free the port.

    On UNIX:

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

    On Windows:

    Stop the component that is using the port.

  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 OID):

    # 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 in the ORACLE_HOME/bin directory:

    On UNIX, run this command: ./config.sh

    On Windows, double-click config.exe

  8. On the Welcome screen, click Next.

  9. On the Select Domain screen, select Configure without a Domain. 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^infradbhost2-vip.example.com:1521:@oid.example.com
      

      Note:

      You must enter the Oracle RAC database connect string information in the short format, for example:

      host1:port1:instance1^host2:port2:instance2@servicename.

      Do not enter the connect string in the long format, which includes the instance names.

      The connect string information must be complete and accurate. Specifically, you must enter the correct host and port for each Oracle RAC instance, and you must enter a service name that is configured for all the specified Oracle RAC instances.

      You must correct manually any incorrect information entered in the Oracle RAC database connect string after the installation.

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

    • 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 OID instance. Therefore, the new OID 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

If you want to manage an OID component with Oracle Enterprise Manager Fusion Middleware Control, you must register the component and the Oracle Fusion Middleware instance that contains it with an Oracle 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.

To register OID components with a WebLogic domain, see "Registering an Oracle Fusion Middleware Instance or Component with the WebLogic Server" in Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory.

8.3.3.3 Configuring Oracle Internet Directory With a WebLogic Domain

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

8.3.3.3.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 OID instance on OIDHOST1:

  1. Ensure that the system, patch, kernel and other requirements are met. See the Oracle Fusion Middleware Installation Guide for Oracle Identity Management.

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

    On UNIX:

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

    On Windows:

    netstat -an | findstr "LISTEN" | findstr ":389"
    
    netstat -an | findstr "LISTEN" | findstr ":636"
    
  4. If the port is in use (if the command returns output identifying the port), you must free the port.

    On UNIX:

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

    On Windows:

    Stop the component that is using the port.

  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 OID):

    # 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 in the ORACLE_HOME/bin:

    On UNIX, run this command: ./config.sh

    On Windows, double-click config.exe

  8. On the Welcome screen, click Next.

  9. On the Select Domain screen, select Create New Domain. Specify the values for:

    • 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: This value is prefilled and cannot be changed.

    • Oracle Home Directory:

      /u01/app/oracle/product/fmw/idm
      
    • WebLogic Server Directory:

      /u01/app/oracle/product/fmw/wlserver_10.3
      
    • Oracle Instance Location:

      /u01/app/oracle/admin/oid_inst1
      
    • Oracle Instance Name:

      oid_inst1
      

      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

      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.

    Note:

    The default Oracle WebLogic Server clustering mode set by the installer is unicast (not multicast).

  14. On the Specify Schema Database screen, select Use Existing Schema and enter 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 installation, it is not required for all 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. On the Configure OID screen, specify the Realm and enter the Administrator (cn=orcladmin) password and 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 launched in succession. When the process completes, click Next.

  19. On the Installation Complete screen, click Finish.

    Note:

    For information on the OID component names assigned by the installer, see Section 8.3.3.2.2, "Oracle Internet Directory Component Names Assigned by Oracle Identity Management Installer."

8.3.3.3.2 Creating boot.properties for the Administration Server on OIDHOST1

The boot.properties file enables the Administration Server to start without prompting for the administrator username and password.

To create the boot.properties file:

  1. On OIDHOST1, go the following directory:

    ORACLE_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 "Starting and Stopping Oracle Fusion Middleware" in Oracle Fusion Middleware Administrator's Guide for information on starting and stopping WebLogic Servers.

  4. Start the Administration Server on OIDHOST1 using the startWebLogic.sh script located under the ORACLE_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.3.3.3.3 Configuring Oracle Internet Directory on OIDHOST2

Ensure that the OID repository is running and then follow these steps to configure the OID instance on OIDHOST2:

  1. Ensure that the system, patch, kernel and other requirements are met. See the Oracle Fusion Middleware Installation Guide for Oracle Identity Management.

  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 OID. The same ports should be used for the OID 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.

    On UNIX:

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

    On Windows:

    netstat -an | findstr "LISTEN" | findstr ":389"
    
    netstat -an | findstr "LISTEN" | findstr ":636"
    
  4. If the port is in use (if the command returns output identifying the port), you must free the port.

    On UNIX:

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

    On Windows:

    Stop the component that is using the port.

  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 OID):

    # 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, located in the ORACLE_HOME/bin directory, as follows:

    On UNIX, issue this command: ./config.sh

    On Windows, double-click config.exe

  8. On the Welcome screen, click Next.

  9. On the Select Domain screen, select Extend Existing Domain and specify the following values.

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

    • Port: 7001 (This is the WebLogic 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: This value is prefilled and cannot be changed.

    • Oracle Home Directory: idm

    • WebLogic Server Directory:

      /u01/app/oracle/product/fmw/wlserver_10.3
      
    • Oracle Instance Location:

      /u01/app/oracle/admin/oid_inst2
      
    • Oracle Instance Name: oid_inst2

      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.

  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 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 OID instance. Therefore, the new OID instance being configured would reuse the same schema.

    Choose Yes to continue.

  16. On the Specify OID Admin 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 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. When it completes, click Next.

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

8.3.4 Validating Oracle Internet Directory High Availability

Use the ldapbind command-line tool to ensure that you can connect to each OID 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 are 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 OID, 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.5 Oracle Internet Directory Failover and Expected Behavior

This section describes how to perform a failover of OID and Oracle RAC.

8.3.5.1 Performing an Oracle Internet Directory Failover

To perform a failover of an OID instance and check the status of OID:

  1. On OIDHOST1, use the opmnctl command to stop the OID instance:

    ORACLE_INSTANCE/bin/opmnctl stopproc ias-component=oid1
    
  2. On OIDHOST2, check the status of OID 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 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 you for a password. LDAP tools are 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 OID 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 OID instance:

    ORACLE_INSTANCE/bin/opmnctl stopproc ias-component=oid1
    
  5. On OIDHOST1, check the status of OID 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 OID instance:

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

8.3.5.2 Performing an Oracle RAC Failover

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 Internet Directory:

    Note:

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

    ldapbind -h oid_host1 -p 389 -D "cn=orcladmin" -q
    ldapbind -h oid_host2 -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 are 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.6 Troubleshooting Oracle Internet Directory High Availability

This section provides information that can help you troubleshoot OID high availability issues:

  • Log files for OID are in directory:

    ORACLE_INSTANCE/diagnostics/log/OID
    
  • 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, OID 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: OID server received a notification from the Oracle process that one of the database node is down. OID 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 OID nodes (oidmon) is not responding.

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

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

8.3.7 Additional Oracle Internet Directory High Availability Issues

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

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

You can change the OID 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 of the OID nodes. However, since the ODS schema password is stored in a password wallet under the ORACLE_INSTANCE of each OID instance, the password wallet must be updated in each OID node.

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

oidpasswd connect=database-connection-string change_oiddb_pwd=true

On all other OID nodes, use 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 OID 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 Oracle RAC nodes, the OID 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.

To fix this issue, 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. Oracle Virtual Directory supports a diverse set of clients, such as Web Applications and portals, and it can connect to directories, databases and Web Services as shown in Figure 8-3.

Figure 8-3 shows Oracle Virtual Directory in a non-high availability architecture.

Figure 8-3 Oracle Virtual Directory in a Non-High Availability Architecture

Description of Figure 8-3 follows
Description of "Figure 8-3 Oracle Virtual Directory in a Non-High Availability Architecture"

The Oracle Virtual Directory server is written in Java and internally it is organized into multiple layers. These layers are logical layers—Oracle Virtual Directory appears as a single complete service to the administrator and to clients.

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. You can also use the Oracle Enterprise Manager Fusion Middleware Control to start and stop Oracle Virtual Directory instances. For more information on using OPMNCTL or Enterprise Manager to start and stop Oracle Virtual Directory instances, 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 has 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.

Based on the nature of the operation, client connections can be persistent or short-lived.

8.4.1.2 Oracle Virtual Directory Component Characteristics

This section describes the various 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.

8.4.2.1 Oracle Virtual Directory High Availability Architecture

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

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

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

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 5.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 Oracle WebLogic Server domain. For information on configuring Oracle Virtual Directory and Oracle Directory Services Manager in a collocated configuration, see Section 8.7, "Collocated Architecture High Availability."

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 an Oracle 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 OVDHOST2" 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. See Oracle Fusion Middleware Installation Guide for Oracle Identity Management.

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

    On UNIX:

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

    On Windows:

    netstat -an | findstr "LISTEN" | findstr ":6501"
    
    netstat -an | findstr "LISTEN" | findstr ":7501"
    
  4. If the port is in use (if the command returns output identifying the port), you must free the port.

    On UNIX:

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

    On Windows:

    Stop the component that is using the port.

  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 in the ORACLE_HOME/bin directory, as follows:

    On UNIX, issue this command: ./config.sh

    On Windows, double-click config.exe

  8. On the Welcome screen, click Next.

  9. On the Select Domain screen, select Configure without a Domain 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_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.

  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. 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=mycompany,dc=com.

      dc=us,dc=mycompany,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. 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.2 Configuring Oracle Virtual Directory on OVDHOST2

To configure the Oracle Virtual Directory instance on OVDHOST2:

Note:

You can use the procedure in this section to scale out Oracle Virtual Directory in an 11g Oracle Identity Management high availability configuration.

  1. Ensure that the system, patch, kernel and other requirements are met. See the Oracle Fusion Middleware Installation Guide for Oracle Identity Management.

  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.

    On UNIX:

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

    On Windows:

    netstat -an | findstr "LISTEN" | findstr ":6501"
    
    netstat -an | findstr "LISTEN" | findstr ":7501"
    
  4. If the port is in use (if the command returns output identifying the port), you must free the port.

    On UNIX:

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

    On Windows:

    Stop the component that is using the port.

  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 in the ORACLE_HOME/bin directory:

    On UNIX, issue this command: ./config.sh

    On Windows, double-click config.exe

  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=mycompany,dc=com.

      dc=us,dc=mycompany,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 that you manage your Oracle Virtual Directory component with Oracle Enterprise Manager Fusion Middleware Control. To do this, you must register the component and Oracle Fusion Middleware instance that contains it with a WebLogic Server domain. You can do this 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 you use the opmnctl registerinstance command to register an Oracle Virtual Directory instance with a domain, ensure that WebLogic Server is installed.

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

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 more on registering Oracle Virtual Directory components with a domain, see "Registering an Oracle Instance Using OPMNCTL" in Oracle Fusion Middleware Administrator's Guide for Oracle Virtual Directory.

8.4.3.2 Configuring Oracle Virtual Directory With a WebLogic Domain

In this configuration, Oracle Virtual Directory and a WebLogic Server domain are configured on the first host. Only Virtual Directory is configured on the second host and this instance 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. See Oracle Fusion Middleware Installation Guide for Oracle Identity Management.

  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.

    On UNIX:

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

    On Windows:

    netstat -an | findstr "LISTEN" | findstr ":6501"
    
    netstat -an | findstr "LISTEN" | findstr ":7501"
    
  4. If the port is in use (if the command returns output identifying the port), you must free the port.

    On UNIX:

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

    On Windows:

    Stop the component that is using the port.

  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 in the ORACLE_HOME/bin directory, as follows:

    On UNIX, issue this command: ./config.sh

    On Windows, double-click config.exe

  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 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 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=mycompany,dc=com.

      dc=us,dc=mycompany,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:

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

  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.

    On UNIX:

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

    On Windows:

    netstat -an | findstr "LISTEN" | findstr ":6501"
    
    netstat -an | findstr "LISTEN" | findstr ":7501"
    
  4. If the port is in use (if the command returns output identifying the port), you must free the port.

    On UNIX:

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

    On Windows:

    Stop the component that is using the port.

  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 in the ORACLE_HOME/bin directory, as follows:

    On UNIX, issue this command: ./config.sh

    On Windows, double-click config.exe

  8. On the Welcome screen, click Next.

  9. On the Select Domain screen, select Extend Existing Domain 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=us,dc=mycompany,dc=com.

      dc=us,dc=mycompany,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 more information about Oracle Virtual Directory Adaptors, see "Understanding Oracle Virtual Directory Adapters" in Oracle Fusion Middleware Administrator's Guide for Oracle Virtual Directory.

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

For information about configuring Database Adapters, see "Configuring Database Adapters" in 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.

Follow the steps below 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 are 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.

This section includes the following topics:

8.4.5.1 Performing an Oracle Virtual Directory Failover

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

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 Oracle Virtual Directory log files can help troubleshoot Oracle Virtual Directory issues. Log files for Oracle Virtual Directory are under the 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 Integration Platform High Availability

This section describes Oracle Directory Integration Platform (ODIP) and how to design and deploy a high availability environment for ODIP.

See Section 8.6, "Oracle Directory Services Manager High Availability" for more information about Oracle Directory Services Manager.

This section includes the following topics:

8.5.1 Oracle Directory Integration Platform Component Architecture

Oracle Directory Integration Platform (ODIP) is a J2EE application that enables you to integrate your applications and directories, including third-party LDAP directories, with an Oracle back-end directory: Oracle Internet Directory (OID), Oracle Unified Directory (OUD), and Oracle Directory Server Enterprise Edition (ODSEE).

Note:

ODIP does not support ODSEE in high availability mode in this release.

See the following topics in Oracle Fusion Middleware Administrator's Guide for Oracle Directory Integration Platform for more on the ODIP architecture:

  • See "Oracle Directory Integration Platform" for more on ODIP architecture.

  • See "Understanding the Oracle Directory Integration Platform Server" for more information on ODIP platform component characteristics: the Oracle Directory Integration Platform Synchronization Service and Provisioning Service.

8.5.2 Oracle Directory Integration Platform High Availability Concepts

This section describes high availability concepts. It includes the following topics:

8.5.2.1 Oracle Directory Integration Platform High Availability Architecture (OID backend)

This section describes ODIP in a typical high availability deployment.

Figure 8-5 shows ODIP with an OID backend in a high availability architecture.

Figure 8-5 Oracle Directory Integration Platform, with OID backend, in a High Availability Architecture

Description of Figure 8-5 follows
Description of "Figure 8-5 Oracle Directory Integration Platform, with OID backend, in a High Availability Architecture"

In Figure 8-5, Connected Directory 1 and Connected Directory 2 replicate information with each other. A load balancing router routes requests to the Connected Directories.

The Application Tier includes the IDMHOST1 and IDMHOST2 computers.

DIP1 and DIP2 go through the load balancer when they must communicate with the Connected Directories.

On IDMHOST1, the following installations are performed:

  • An ODIP instance is installed (DIP1) on the Managed Server.

  • A Quartz Scheduler is installed with DIP1 by default. It connects to the Oracle RAC database using a WebLogic multi data source. The Quartz Scheduler invokes EJBs that do the actual work; if the EJB fails, the Quartz Scheduler marks the job as failed and reschedules it to run at later time by another EJB.

  • An Administration Server is installed. Under normal operations, this is the active Administration Server.

On IDMHOST2, the following installations are performed:

  • An ODIP instance is installed (DIP2) on the Managed Server.

  • A Quartz Scheduler is installed on DIP2. Quartz Scheduler connects to the Oracle RAC database using a WebLogic multi data source.

  • An Administration Server is installed. Under normal operations, this is the passive Administration Server instance. You make this Administration Server active if the Administration Server on IDMHOST1 becomes unavailable.

The ODIP instances on the IDMHOST1 and IDMHOST2 Managed Servers are configured as a cluster.

A load balancer is set up for the back-end directories OIDHOST1 and OIDHOST2. The load balancer routes requests to either OIDHOST1 or OIDHOST2.

Note:

When you use a RAC database, multi data source is used with DIP to protect the instances from RAC failure.

8.5.2.1.1 Starting and Stopping the Cluster

By default, the WebLogic Server starts, stops, and monitors the applications and ODIP leverages the high availability features of the underlying clusters. If there is a hardware or other failure, session state is available to other cluster nodes that can resume the work of the failed node.

Node Manager monitors the WebLogic servers. If failure occurs, Node Manager restarts the WebLogic Server.

Note:

See "General Node Manager Configuration" in Oracle Fusion Middleware Node Manager Administrator's Guide for Oracle WebLogic Server for more information on Node Manager.

8.5.2.1.2 Cluster-Wide Configuration Changes (OID)

When you deploy Oracle Internet Directory (OID) in a high availability configuration, all OID instances in the cluster share the same database. Any changes made to ODIP on one OID node automatically propagate to all the Oracle Internet Directory instances in the cluster.

Note:

The following topics describe configuration changes made to the ODIP application in an OID multimaster replication deployment. In a multimaster replication deployment, you must apply configuration changes manually to all nodes in the cluster.

Directory Synchronization Profiles

Changes that you make to directory integration profiles on one Oracle Internet Directory (OID) node do not replicate automatically to other OID nodes in a default multimaster OID replication environment. You must copy changes from the primary node to the secondary nodes manually and do so on a periodic basis. By doing this, a directory synchronization profile can run on a secondary node if a problem occurs on the primary node.

ODIP uses the parameter orcllastappliedchangenumber. The value assigned to the lastchangenumber attribute in a directory synchronization profile depends on the directory server on which ODIP is running. In an active-active ODIP configuration, you must manually update the lastchangenumber attribute in all instances.

To synchronize directory provisioning profiles between the primary OID node and secondary nodes:

  1. On the primary node, use the ldifwrite command to create an LDIF dump of the entries from this container:

    cn=subscriber 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.

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 Managed Server instance.

  5. Go to the ODIP Admin console and select the profile. Select Edit. Select the Advanced tab then select Edit and Persist. Enter the value that Step 2 returned. Save the profile.

  6. Enable the synchronization profile.

Directory Provisioning Profiles

In a default multimaster Oracle Internet Directory replication environment, ODIP is installed in the same location as the primary Oracle Internet Directory. The information and steps in this topic applies 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 do not propagate to any applications that expect them. To ensure that events continue to propagate 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, copy directory provisioning profiles 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 directory provisioning profiles between a primary node and any secondary nodes:

  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.5.2.2 Oracle Directory Integration Platform High Availability Architecture (OUD Backend)

This section describes the ODIP High Availability Architecture with an OUD backend.

Figure 8-6 ODIP, with OUD backend, in a High Availability Architecture

Description of Figure 8-6 follows
Description of "Figure 8-6 ODIP, with OUD backend, in a High Availability Architecture"

In Figure 8-6, Connected Directory 1 and Connected Directory 2 replicate information with each other. A load balancing router routes requests to the Connected Directories.

The Application Tier includes the IDMHOST1 and IDMHOST2 computers.

On IDMHOST1, the following installations are performed:

  • An ODIP instance is installed (DIP1) on the Managed Server. DIP1 goes through the load balancer for connected directories when it must connect to them.

  • The Quartz Scheduler is installed. It goes through the load balancer for backend directories.

  • An Administration Server is installed. Under normal operations, this is the active Administration Server.

On IDMHOST2, the following installations are performed:

  • An ODIP instance is installed (DIP2) on the Managed Server. DIP2 goes through the load balancer for connected directories when it must connect to them.

  • The Quartz Scheduler is installed. It goes through the load balancer for backend directories.

  • An Administration Server is installed. Under normal operations, this is the passive Administration Server instance. You make this Administration Server active if the Administration Server on IDMHOST1 becomes unavailable.

The ODIP instances on the IDMHOST1 and IDMHOST2 Managed Servers are configured as a cluster.

A load balancer is set up for the back-end directories OUDHOST1 and OUDHOST2. The load balancer routes requests to either OUDHOST1 or OUDHOST2.

8.5.2.2.1 Cluster-Wide Configuration Changes (OUD)

All OUD instances that are part of the same replication topology share the same content. Any changes made to ODIP on one OUD node automatically propagate to all OUD instances in the replication topology.

8.5.2.3 Protection from Failures and Expected Behavior

This section describes protection from different types of failure in an ODIP active-active cluster and includes the following topics:

8.5.2.3.1 Process Failure

In a high availability environment, you deploy the ODIP application to a cluster that comprises at least two WebLogic instances.

By default, the ODIP application leverages high availability features of the underlying WebLogic clusters. When you deploy ODIP, the Quartz scheduler starts with a clustering option. Depending on the load on the node, the scheduler then runs the job on any available nodes in the cluster. If hardware or other failures occur on one or more nodes, the Quartz scheduler runs the jobs on available nodes.

Also, Node Manager monitors WebLogic servers. In case of failure, Node Manager restarts the WebLogic server.

Within the ODIP 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. If the EJB fails, the Quartz scheduler marks the job as failed and reschedules it to run later by another EJB.

8.5.2.3.2 Updating the Oracle Directory Integration Platform Server Configuration

If the backend server is not accessed or cannot be accessed through a load balancer, ODIP failover is not transparent. This scenario requires manual intervention because the information to connect to the backend directory is local to each ODIP instance. You must use the manageDIPServerConfig utility to update the backend directory host:port on all ODIP instances.

See Oracle Fusion Middleware Administrator's Guide for Oracle Directory Integration Platform for more information about the manageDIPServerConfig utility.

8.5.2.3.3 External Dependency Failure

ODIP requires the back-end repository, Oracle Internet Directory, Credential Store Framework, and the WebLogic Managed Server to be available during startup. ODIP fails to start if any one of these elements is unavailable.

8.5.2.4 Oracle Directory Integration Platform Prerequisites

To set up Oracle Directory Integration Platform (ODIP) in a high availability architecture, you must install and configure Oracle Internet Directory and Oracle Unified Directory.

Note:

ODIP uses the Quartz Scheduler to maintain its jobs and schedules in the Oracle RAC database. For Quartz Scheduler jobs to run on multiple ODIP nodes in a cluster, system clocks on cluster nodes must be synchronized.

8.5.2.4.1 Installing and Configuring Oracle Internet Directory

See the following topics to install and configure OID:

8.5.2.4.2 Installing and Configuring Oracle Unified Directory

Take one of the following actions, depending on whether or not you installed Oracle Unified Directory (OUD):

  • If you have not installed OUD, use the Configuration Wizard to install it. You must select Enable for DIP (Directory Integration Platform) in the Configuration Wizard's Oracle Components Integration page. When installation is complete, complete the following steps.

  • If you installed OUD, you must create the suffix cn=oraclecontext for ODIP to use:

    1. Run the script oud-instance/bin/setup-oracle-context to create the suffix cn=oraclecontext.

    2. Verify that the changelog on cn=oraclecontext is enabled. The script setup-oracle-context configures the changelog if replication was already enabled on the OUD instance. If the changelog on cn=oraclecontext is not enabled, run the dsreplication command from that OUD instance.

8.5.3 Configuring Oracle Directory Integration Platform for High Availability

This section includes the following topics:

8.5.3.1 Configuring High Availability for an OID Backend Server

This section describes how to perform the following installation and configuration steps on IDMHOST1 and IDMHOST2:

8.5.3.1.1 Configuring Oracle Directory Integration Platform on IDMHOST1 (OID)

To configure ODIP on IDMHOST1:

  1. Ensure that the system, patch, kernel, and other requirements are met. See Oracle Fusion Middleware Installation Guide for Oracle Identity Management for the platform and version you are using.

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

  3. Ensure that port 7006 is not used by any service on IDMHOST1 by running these commands for the operating system you are using. (If a port is not in use, there is no output from the command.)

    On UNIX:

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

    On Windows:

    netstat -an | findstr "LISTEN" | findstr ":7006"
    
  4. If the port is in use (the command returns output identifying the port), free the port.

    On UNIX:

    Remove the entries for port 7006 in the /etc/services file and restart the services, or restart the computer.

    On Windows:

    Stop the component that is using the port.

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

  6. Start the Configuration Wizard, located in the ORACLE_HOME/bin directory:

    The ORACLE_HOME environment variable and related directory path refers to the location where Fusion Middleware (FMW) resides.

    On UNIX, issue this command: ./config.sh

    On Windows, double-click config.exe

  7. On the Welcome screen, click Next.

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

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

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

  10. On the Specify Oracle Configuration Manager Details screen, specify these values:

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

    • Oracle Support Password: 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 Directory Integration Platform, Management Components - Oracle Directory Services Manager. Deselect all the other components. Ignore the warning that says Oracle Internet Directory must be configured as a prerequisite.

    Select the Clustered check box.

    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 OID Details screen, specify the following information. This information might be your load-balanced IP address.

    • Hostname: oid.example.com

    • Port: 636

    • Username: cn=orcladmin

    • Password: ******

    Click Next.

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

    • Connect String:

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

      Note:

      You must provide the Oracle RAC database connect string in the format host1:port1:instance1^host2:port2:instance2@servicename.

      Installation can proceed as long as one Oracle RAC instance is up.

      The information provided must be complete and accurate. You must enter the correct host, port, and instance name for each Oracle RAC instance, and the service name must be configured for all the Oracle RAC instances.

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

    • User Name: ODSSM

    • Password: ******

    Click Next.

  15. On the Installation Summary screen, review the selections to ensure that they are correct and click Install.

  16. On the Installation Progress screen (UNIX), a dialog box prompts you to run the oracleRoot.sh script. Open a window and run the script.

    Click Next.

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

  18. On the Installation Complete screen, click Finish.

8.5.3.1.2 Creating boot.properties for the Administration Server on IDMHOST1 (OID)

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

To create the boot.properties file:

  1. On IDMHOST1, go the following directory:

    ORACLE_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 IDMHOST1 using the startWebLogic.sh script located in the ORACLE_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.5.3.1.3 Configuring Oracle Directory Integration Platform on IDMHOST2 (OID)

To configure ODIP and Oracle Directory Services Manager on IDMHOST2:

  1. Ensure that the system, patch, kernel and other requirements are met. See the Oracle Fusion Middleware Installation Guide for Oracle Identity Management for the platform and version you are using.

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

  3. Start the Configuration Wizard from the ORACLE_HOME/bin directory:

    On UNIX, issue this command: ./config.sh

    On Windows, double-click config.exe

  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 checks. 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:

    The 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 path name 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, the oracleRoot.sh confirmation dialog box opens.

    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.

8.5.3.1.4 Post-Installation Steps for Oracle Directory Integration Platform (OID)

In Section 8.5.3.1.3, the installer created a second Managed Server, wls_ods2, on IDMHOST2. However, the ODIP 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 these post-installation steps to complete the installation and configuration of the ODIP and Oracle Directory Services Manager applications on IDMHOST2.

8.5.3.1.5 Copy the Oracle Directory Integration Platform Configuration from IDMHOST1 to IDMHOST2

To copy the ODIP application directly from IDMHOST1 to IDMHOST2:

Copy the following directory on IDMHOST1:

ORACLE_HOME/user_projects/domains/IDMDomain/config/fmwconfig/servers/wls_ods1

To the following location on IDMHOST2:

ORACLE_HOME/user_projects/domains/IDMDomain/config/fmwconfig/servers/wls_ods2

8.5.3.1.6 Restart the Managed Server on IDMHOST2 in a Cluster

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.

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.

  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.5.3.2 Configuring High Availability for an OUD Backend Server

This topic describes how to configure Oracle Directory Integration Platform (ODIP) with OUD as the backend server.

To configure ODIP and OUD high availability, follow these steps:

8.5.3.2.1 Configuring Oracle Directory Integration Platform on IDMHOST1 (OUD)

To configure ODIP on IDMHOST1:

  1. Verify that system, patch, kernel and other requirements are met. See Oracle Fusion Middleware Installation Guide for Oracle Identity Management for the platform and version you are using.

  2. Ensure that WebLogic Server and Oracle Identity Management software is installed and upgraded on IDMHOST1. See Section 8.3.3.1, "Installing Oracle Fusion Middleware Components".

  3. Start the Configuration Wizard in ORACLE_HOME/oracle_common/common/bin:

    On UNIX, issue this command: ./config.sh

    On Windows, double-click config.exe

  4. On the Welcome screen, click Next.

  5. On the Select Domain screen, select Create a new WebLogic domain and click Next:

  6. Select Generate a domain configured automatically to support the following products: and select the following templates:

    • Oracle Enterprise Manager

    • Oracle Directory Integration Platform

    • Oracle Identity Management

    • Oracle JRF

    Select Next.

  7. On the Specify Domain Name and Location screen, enter the name and location for the domain and all its applications.

    • Domain Name: IDMDomain

    • Domain Location: Accept the default.

    • Application Location: Accept the default.

  8. On the Configure Administrator User Name and Password screen, enter the Administrator username and password:

    Click Next.

  9. On the Configure Server Start Mode and JDK screen, select Production Mode. In the JDK Selection section, select a JDK from the list of available JDKs, or select Other JDK then click Browse to find another JDK on your system.

    Click Next.

  10. On the Select Optional Configuration screen, select Managed Servers, Clusters, and Machines.

    Click Next.

  11. On the Configure Managed Servers screen, create an entry for each host in the topology, that is, one for the ODIP Server running on IDMHOST1 and one for the ODIP Server running on IDMHOST2.

    Select the ODIP_SERVER entry and change the entry to the following values:

    • Name: WLS_ODS1

    • Listen Address: IDMHOST1.example.com

    • Listen Port: 7005

    For the second ODIP, click Add and enter the following information:

    • Name: WLS_ODS2

    • Listen Address: IDMHOST2.example.com

    • Listen Port: 7005

    Click Next.

  12. On the Configure Clusters screen, add the following values:

    • Name: ODIP_CLUSTER1

    • Cluster messaging mode: unicast

    • Cluster Address: WLS Cluster IP address (optional)

  13. On the Assign Servers to Clusters screen, associate the managed servers with the cluster, as follows:

    • Click the cluster name ODIP_CLUSTER1 in the right window.

    • Click the managed server WLS_ODS1, then click the arrow to assign it to the cluster.

    • Repeat for managed server WLS_ODS2.

    Click Next.

  14. On the Configure Machines screen, create a machine for each host in the topology. Click the UNIX tab if your hosts use a UNIX-based operating system. Otherwise, click the Machines tab. Enter the following information:

    • Name: Name of the host. The best practice is to use the DNS name (IDMHOST1)

    • Node Manager Listen Address: The DNS name of the machine (IDMHOST1.example.com)

    • Node Manager Port: A port for Node Manager to use.

    Repeat the steps for IDMHOST2:

    • Name: Name of the host. The best practice is to use the DNS name (IDMHOST2)

    • Node Manager Listen Address: The DNS name of the machine (IDMHOST2.example.com)

    • Node Manager Port: A port for Node Manager to use.

    Click Next.

  15. In the Assign Servers to Machines screen, indicate which managed servers will run on the machines just created.

    • Click the machine IDMHOST1 in the right window.

    • Click the managed server WLS_ODS1 in the left window.

    • Click the arrow to assign the managed server to the host IDMHOST1.

    • Click the machine IDMHOST2 in the right window.

    • Click the managed server WLS_ODS2 in the left window.

    • Click the arrow to assign the managed server to the host IDMHOST2.

    Click Next.

  16. On the Configuration Summary screen, review your selections to ensure that they are correct and click Create.

  17. On the Creating Domain screen, follow the process. Click Done when complete.

8.5.3.2.2 Creating boot.properties for the Administration Server on IDMHOST1

See Section 8.5.3.1.2, "Creating boot.properties for the Administration Server on IDMHOST1 (OID)" to create the Administration Server boot.properties.

8.5.3.2.3 Starting the Administration Server

If it is not running, use the startWebLogic.sh script to start the Administration Server on IDMHOST1:

cd MW_HOME/user_projects/domains/domainName/bin
./startWebLogic.sh &

If it is not running, start the Managed Server on IDMHOST1:

  1. Open the Administration Console at http://IDMHOST1:7001/console.

  2. Select the Managed Server WLS_ODS1, select the Control Tab, then select Start.

8.5.3.2.4 Configuring Oracle Directory Integration Platform on IDMHOST2 (OUD)

Ensure that Oracle Identity Management software is installed and upgraded on IDMHOST2. See Section 8.3.3.1, "Installing Oracle Fusion Middleware Components."

8.5.3.2.5 Starting Node Manager on IDMHOST2 (OUD)

To start an instance of Node Manager on IDMHOST2:

  1. Run the setNMProps.sh script in the directory MW_HOME/oracle_common/common/bin to set the StartScriptEnabled property to true before you start Node Manager:

    cd ORACLE_COMMON_HOME/common/bin
    ./setNMProps.sh
    

    Note:

    You must use the StartScriptEnabled=true property to avoid class loading failures and other problems.

  2. Start Node Manager:

    cd WL_HOME/server/bin
     ./startNodeManager.sh
    
8.5.3.2.6 Registering the OUD Back-end Directory with Oracle Directory Integration Platform

This topic describes how to register the OUD back-end directory with ODIP. You run the dipConfigurator command on both hosts to register the directory. The dipConfigurator command performs the following steps:

  • Loads the schema that ODIP requires into OUD

  • Loads the ODIP content in cn=oraclecontext suffix

  • Creates an ODIP user

  • Applies specific ACIs for the ODIP user

To register OUD back-end directories with ODIP:

  1. On IDMHOST1, run the following:

    cd ORACLE_HOME/bin
    
    ./dipConfigurator setup -wlshost IDMHOST1 -wlsport 7001 -wlsuser weblogic -ldaphost OUDHOST1 -ldapport OUD_LDAP_PORT1 -ldapuser "cn=Directory Manager" -ldapadminport OUD_LDAP_ADMIN_PORT1 -isldapssl false -isclustered true
    
    ./dipConfigurator setupSecondaryBackend -ldaphost OUDHOST2 -ldapport OUD_LDAP_PORT2 -ldapuser "cn=Directory Manager" -ldapadminport OUD_LDAP_ADMIN_PORT2 -isldapssl false
    
  2. Tune the cluster with the command manageDIPServerConfig:

    ./manageDIPServerConfig set -host IDMHOST1 -port 7005 -wlsuser weblogic -attribute ClusterCheckInInterval -value 30000
    ./manageDIPServerConfig set -host IDMHOST1 -port 7005 -wlsuser weblogic -attribute RefreshInterval -value 120
    
  3. Reconfigure ODIP to use the TCP load balancer.

    LB_HOST is the load balancer IP address you must configure to redirect to one of the backend instances.

    ./manageDIPServerConfig set -host IDMHOST1 -port 7005 -wlsuser weblogic -attribute BackendHostPort -value LB_HOST:LB_PORT
    
8.5.3.2.7 Configuring ODIP2

To configure ODIP2:

  1. Copy the file dip-config.xml on IDMHOST1:

    cp MW_HOME/user_projects/domains/DOMAIN_NAME/config/fmwconfig/servers/wls_ods1/applications/DIP_11.1.1.2.0/configuration/dip-config.xml /tmp

  2. Start and stop Managed Server 2 on IDMHOST1:

    MW_HOME/user_projects/domains/base_domain/bin/startManagedWebLogic.sh wls_od2
    MW_HOME/user_projects/domains/base_domain/bin/stopManagedWebLogic.sh wls_od2
    
  3. Overwrite the dip-config.xml file on the wls_ods1 by previous backup:

    cp /tmp/dip-config.xml MW_HOME/user_projects/domains/DOMAIN_NAME/config/fmwconfig/servers/wls_ods2/applications/DIP_11.1.1.2.0/configuration/dip-config.xml
    
  4. Run the following pack command on IDMHOST1 to create a template pack:

    cd MW_HOME/oracle_common/common/bin
    ./pack.sh -managed=true -domain=MW_HOME/user_projects/domains/domainName -template=dipdomain.jar -managed=true -template_name="dipdomain"
    
  5. Copy the template file created in the previous step from IDMHOST1 to IDMHOST2. For example, on a UNIX platform:

    scp dipdomain.jar user@IDMHOST2:MW_HOME/oracle_common/common/bin
    
  6. Run the unpack command on IDMHOST2 to unpack the propagated template:

    cd MW_HOME/oracle_common/common/bin 
    ./unpack.sh -domain=MW_HOME/user_projects/domains/domains/domainName -template=dipdomain.jar -overwrite_domain=true
    
  7. Start Managed Server on IDMHOST2:

    MW_HOME/user_projects/domains/DOMAIN_NAME/bin/startManagedWebLogic.sh wls_ods2 t3://IDMHOST1:7001
    
8.5.3.2.8 Configuring the Load Balancer

Oracle recommends configuring the load balancer to support failover mode compared to round robin or other modes. The load balancer must support long-lasting LDAP connections so that ODIP can process long batches of data. It is not unusual for ODIP to keep connections open longer than 10 minutes.

8.5.4 Connected Directories

Oracle Directory Integration Platform (ODIP) uses readers to retrieve changes from connected directories. However, there are some connectors that you cannot use for load-balanced directories. This section describes how ODIP supports the use of several instances of a connected directory for import profiles.

8.5.4.1 Failing Over Oracle Directory Server Enterprise Edition Manually

ODIP does not support transparent failover from one Oracle Directory Server Enterprise Edition (ODSEE) Managed Server (WLS_ODSEE1) to another ODSEE server (WLS_ODSEE2). Even if you replicate ODSEE Managed Server instances, the change numbers may not be identical on both ODSEE Managed Servers for the same update. If ODIP fails over transparently from WLS_ODSEE1 to WLS_ODSEE2, ODIP may replay changes or miss changes each time it switches.

To manually failover an ODSEE Managed Server, see "Directory Synchronization Profiles."

8.5.4.2 Oracle Unified Directory

When you use OUD with Iplanet Reader and Iplanet Writer, OUD does not support transparent failover from one OUD instance to another because, as with ODSEE Server, change numbers may not be synchronized. However, you can configure your profile to use an OUD connector that does support it.

To configure your profile, you must set the reader to oracle.ldap.odip.gsi.OudCookieReader. You must configure this attribute at creation time; you cannot configure it for existing profiles.

To configure your profile:

  1. Go to the directory ORACLE_HOME/ldap/odi/conf and edit the file iplanetimp.cfg.master

  2. Replace the line: Reader: oracle.ldap.odip.gsi.IPlanetReader with the line oracle.ldap.odip.gsi.OudCookieReader

To failover transparently from one OUD instance to another, the reader uses the External Change Log cookie that OUD provides. The last applied change number contains a cookie but no longer contains a change number.

See "Using the External Change Log" in the Oracle Fusion Middleware Administrator's Guide for Oracle Unified Directory for more information on OUD external change log cookies.

8.5.4.3 Microsoft Active Directory

Oracle Directory Integration Platform offers two ways to synchronize with Microsoft Active Directory: the USNChanged approach and the DirSync approach. Only the DirSync approach permits transparent failover from one instance to the other.

See "Synchronizing from Microsoft Active Directory to the Oracle Back-end Directory" in the guide Oracle Fusion Middleware Administrator's Guide for Oracle Directory Integration Platform.

8.5.4.4 Novell eDirectory

Because the ODIP reader for Novell eDirectory is based on timestamps, clocks on all instances must be synchronized.

8.5.4.5 OpenLDAP

Because ODIP reader for OpenLDAP is based on timestamps, clocks on all instances must be synchronized.

8.5.4.6 IBM Tivoli Directory Server

Oracle does not support Tivoli by means of the load balancer.

8.5.4.7 Oracle Internet Directory

If you configure Oracle Internet Directory (OID) replication so that change numbers are identical on all OID instances that you target, the OID instances can failover transparently. If you do not set up this configuration, transparent failover is not supported.

8.5.5 Oracle Directory Integration Platform Failover and Expected Behavior

In a high availability environment, you deploy the ODIP application on a WebLogic Server cluster that comprises at least two WebLogic instances.

By default, the ODIP application leverages 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, Node Manager is configured to monitor the WebLogic servers. In case of failure, Node Manager restarts the WebLogic Server.

If an instance of OID fails, the load balancer redirects to the surviving instance of OID and the Oracle RAC database. If OUD fails, the load balancer redirects to the surviving instance of OUD.

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; see Section 8.5.6, "Troubleshooting Oracle Directory Integration Platform High Availability."

8.5.6 Troubleshooting Oracle Directory Integration Platform High Availability

This section describes how to manage issues involving Oracle Directory Integration Platform (ODIP) high availability. Topics in this section include:

8.5.6.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 ODIP 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 ODIP application recovers and begins to operate normally after a lag of one or two minutes. During an Oracle RAC failover, there will be no ODIP 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 exceptions are 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.5.6.2 Dealing with Error Messages Received After Starting WebLogic Node Manager

If you see the following error message after starting Node Manager, follow the procedure described 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, click Lock & Edit in the Change Center of the Administration Console.

  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.5.6.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.5.6.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 one ODIP instance in a high availability topology, the configuration change does not propagate automatically to all ODIP instances in the topology.

Use the manageDIPServerConfig tool to make a configuration change to all ODIP instances in the topology, ensuring the same configuration across all ODIP instances. See Oracle Fusion Middleware Administrator's Guide for Oracle Directory Integration Platform for more information about the manageDIPServerConfig tool.

8.5.6.5 Operation Cannot Be Completed for Unknown Errors Message

Sometimes the following error message appears intermittently when you use the manageSyncProfiles command:

OPERATION CANNOT BE COMPLETED FOR UNKNOWN ERRORS

If you see this error message, start and stop the Managed Server (wls_ods1 or wls_ods2). If the problem persists, repeat the copy method on the second node.

8.6 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 ODIP and Oracle Directory Services Manager.

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

This section includes the following topics:

8.6.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 is a replacement for 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, 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-7 shows the Oracle Directory Services Manager architecture.

Figure 8-7 Oracle Directory Services Manager Architecture

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

Figure 8-7 shows Oracle Directory Services Manager deployed in non-high availability architecture. Oracle Directory Services Manager is deployed on the Oracle WebLogic Server. Oracle Directory Services Manager 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.6.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 Oracle WebLogic 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.

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 Oracle 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. Node Manager is configured to monitor the server process and restarts it in case of failure.

8.6.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:

Use the following tools to start and stop Oracle Directory Services Manager processes:

  • Oracle WebLogic Server Scripting Tool (WLST)

  • Oracle Enterprise Manager Fusion Middleware Control

  • WebLogic Server Administration Console

  • WebLogic Node Manager

8.6.1.1.2 Oracle Directory Services Manager Log File

Oracle Directory Services Manager messages are logged in the server log file of the Oracle 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.6.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 ODIP are installed and configured on two hosts in a two-node high availability active-active configuration.

8.6.2.1 Oracle Directory Services Manager High Availability Architecture

Figure 8-8 shows the ODIP and Oracle Directory Services Manager high availability architecture in an active-active configuration.

Figure 8-8 Oracle Directory Services Manager and Oracle Directory Integration Platform in a High Availability Architecture

Description of Figure 8-8 follows
Description of "Figure 8-8 Oracle Directory Services Manager and Oracle Directory Integration Platform in a High Availability Architecture"

In Figure 8-8, the application tier includes the IDMHOST1 and IDMHOST2 computers.

On IDMHOST1, the following installations have been performed:

  • An ODIP instance and Oracle Directory Services Manager instance are installed on the WLS_ODS1 Managed Server. The Oracle RAC database is configured in a JDBC multi data source to protect the instances from Oracle RAC node failure.

  • A WebLogic Administration Server is installed. Under normal operations, this is the active Administration Server.

On IDMHOST2, the following installations have been performed:

  • An ODIP instance and Oracle Directory Services Manager instance are 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, ODIP 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 ODIP 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, Node Manager is configured to monitor 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.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.6.2.2.1 Process Failure

In a high availability environment, the Oracle Directory Services Manager applications are deployed on an Oracle 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.

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.6.2.2.2 Expected Client Application Behavior When Failure Occurs

Oracle Directory Services Manager failover is not transparent. You must reestablish the connection during an Oracle WebLogic Server instance failover using Oracle Directory Services Manager.

8.6.2.2.3 External 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.6.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.6.3 Oracle Directory Services Manager High Availability Configuration Steps

See Section 8.5.3.1, "Configuring High Availability for an OID Backend Server" to install and configure the high availability active-active configuration in Figure 8-8.

8.6.4 Validating Oracle Directory Services Manager High Availability

This section describes how to validate Oracle Directory Services Manager in a high availability configuration.

8.6.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://admin.example.com

Perform these steps:

  1. Access Oracle Directory Services Manager through the Oracle HTTP Server virtual server name:

    http://admin.example.com/odsm/faces/odsm.jspx
    
  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 Oracle WebLogic Server 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://admin.example.com/odsm/faces/odsm.jspx
    

    The Welcome to Oracle Directory Services Manager screen is displayed.

8.6.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://admin.example.com

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://admin.example.com/odsm/faces/odsm.jspx
    

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

    MW_HOME/bin/srvctl stop instance -d infradb -i infradb1
    MW_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:

    MW_HOME/oracle_common/common/bin/srvctl start instance -d infradb -i infradb1
    MW_HOME/oracle_common/common/bin/srvctl status database
    
  6. Repeat steps 3, 4, and 5 for INFRADBHOST2-VIP.

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

8.6.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.6.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.6.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.6.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.6.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.6.6 Troubleshooting Oracle Directory Services Manager

This section describes how to resolve Oracle Directory Services Manager high availability issues.

8.6.6.1 Resolving Error Messages Received After Starting WebLogic Node Manager

If the following error message appears after you start Node Manager, see the procedure 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. 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.6.6.2 If WebLogic Node Manager Fails to Start

If 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.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 Oracle WebLogic Server 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.6.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.6.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.6.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.7 Collocated Architecture High Availability

This section describes how to design and deploy Oracle Internet Directory, Oracle Directory Integration Platform (ODIP), Oracle Virtual Directory, and Oracle Directory Services Manager in collocated high availability environments. An introduction to these components is provided in previous sections.

This section describes the collocated architecture for Oracle Internet Directory, ODIP, Oracle Virtual Directory and Oracle Directory Services Manager when deployed in a high availability configuration.

This section includes the following topics:

8.7.1 Collocated Architecture Overview

See the sections below for an architecture overview of each component in the collocated architectures described in this section:

Figure 8-9 shows Oracle Internet Directory, ODIP, Oracle Virtual Directory, and Oracle Directory Services Manager collocated on a single host and deployed in a non-high availability architecture.

Figure 8-9 Collocated Components Architecture

Description of Figure 8-9 follows
Description of "Figure 8-9 Collocated Components Architecture"

All the components in Figure 8-9 are deployed on the same host, but have separate Oracle homes and Oracle instances. Oracle Internet Directory uses a standalone Oracle database as the security metadata repository.

8.7.2 Collocated Architecture High Availability Deployment

Figure 8-10 shows Oracle Internet Directory, Oracle Virtual Directory, ODIP, and Oracle Directory Services Manager collocated on IDMHOST1 and IDMHOST2 and deployed in a high availability architecture.

Figure 8-10 Collocated Components in a High Availability Architecture

Description of Figure 8-10 follows
Description of "Figure 8-10 Collocated Components in a High Availability Architecture"

8.7.2.1 Collocated Architecture Prerequisites

See the sections below for the prerequisites of each component in the collocated architectures described in this section:

8.7.2.2 Configuring Collocated Components for High Availability

This section provides the steps to install and configure Oracle Internet Directory, ODIP, Oracle Virtual Directory and Oracle Directory Services Manager on IDMHOST1 and IDMHOST2 in a high availability architecture:

Note:

In a collocated environment, the Oracle Identity Management components should be installed in separate Oracle Homes. They can share the same MW_HOME.

For each component, ensure that the Oracle Home Location directory path for the first instance is the same as the Oracle Home Location directory path for the second instance.

For example, if the Oracle Home Location directory path for the first Oracle Internet Directory instance on OIDHOST1 is /u01/app/oracle/product/fmw/idm, then the Oracle Home Location directory path for the second Oracle Internet Directory instance on OIDHOST2 must also be /u01/app/oracle/product/fmw/idm.

  1. Install the database. For more information, see Section 8.2.3, "Installing and Configuring the Database Repository."

  2. Install RCU. For more information, see Section 8.2.4, "Obtaining the Repository Creation Utility Software."

  3. Configure the database. For more information, see Section 8.2.5, "Configuring the Database for Oracle Fusion Middleware 11g Metadata."

  4. Run RCU to install the required schemas for Oracle Internet Directory and Oracle Identity Federation. For more information, see Section 8.3.2.3.2, "Using RCU to Create Oracle Internet Directory Schemas in the Repository".

  5. Install and configure Oracle Internet Directory on the first host. For more information, see Section 8.3.3.2.1, "Configuring Oracle Internet Directory on OIDHOST1" or Section 8.3.3.3.1, "Configuring Oracle Internet Directory on OIDHOST1."

  6. Install and configure Oracle Internet Directory on the second host. For more information, see Section 8.3.3.2.3, "Configuring Oracle Internet Directory on OIDHOST2" or Section 8.3.3.3.3, "Configuring Oracle Internet Directory on OIDHOST2."

  7. Install and configure Oracle Virtual Directory on the first host. For more information, see Section 8.4.3.1.1, "Configuring Oracle Virtual Directory on OVDHOST1" or Section 8.4.3.2.1, "Configuring Oracle Virtual Directory on OVDHOST1."

  8. Install and configure Oracle Virtual Directory on the second host. For more information, see Section 8.4.3.1.2, "Configuring Oracle Virtual Directory on OVDHOST2" or Section 8.4.3.2.3, "Configuring Oracle Virtual Directory on OVDHOST2."

  9. Install and configure ODIP and Oracle Directory Services Manager on the first host. For more information, see Section 8.5.3.1.1, "Configuring Oracle Directory Integration Platform on IDMHOST1 (OID)."

  10. Install and configure ODIP and Oracle Directory Services Manager on the second host. For more information, see Section 8.5.3.1.3, "Configuring Oracle Directory Integration Platform on IDMHOST2 (OID)."

8.7.3 Validating the Collocated Components High Availability

The following topics have information about validating components in collocated high availability architectures and about how to failover components and Oracle RAC.

8.7.3.1 Validation Tests

See the sections below for information on validating the following components in the collocated high availability architectures:

8.7.3.2 Failures and Expected Behaviors

See the sections below for information on failures and expected behaviors for the following components in the collocated high availability architectures:

8.7.4 Troubleshooting Collocated Components Manager High Availability

See the sections below for information on troubleshooting the following components in collocated high availability architectures:

8.7.5 Additional Considerations for Collocated Components High Availability

See these sections for additional considerations in collocated high availability architectures:

8.8 Starting and Stopping Components

To start and stop components, see the topic Starting and Stopping Components in the Oracle Fusion Middleware Administrator's Guide.