7 Configuring High Availability for Identity Management Components

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

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

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

This chapter includes the following topics:

Section 7.1, "Identity Management Product Components and High Availability Concepts"
Section 7.2, "Prerequisites for Oracle Identity Management High Availability Configuration"
Section 7.3, "Oracle Internet Directory High Availability"
Section 7.4, "Oracle Virtual Directory High Availability"
Section 7.5, "Oracle Directory Integration Platform High Availability"
Section 7.6, "Oracle Directory Services Manager High Availability"
Section 7.7, "Oracle Identity Federation High Availability"
Section 7.8, "Collocated Architecture High Availability"

7.1 Identity Management Product Components and High Availability Concepts

Figure 7-1 shows the Oracle Fusion Middleware 11g Oracle Identity Management high availability architecture. This architecture includes a web tier, application tier, and directory tier.

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

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

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

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

The application tier includes the IDMHOST1 and IDMHOST2 computers.

On IDMHOST1, the following installations have been performed:

An Oracle Directory Services Manager instance and an Oracle Directory Integration Platform instance have been installed in the WLS_ODS1 Managed Server. The RAC database has been configured in a JDBC multi data source to protect the instances from RAC node failure.
An Oracle Identity Federation instance has been installed in the WLS_OIF1 Managed Server. The RAC database has been configured in a JDBC multi data source to protect the instance from RAC node failure.
A WebLogic Administration Server has been installed. Under normal operations, this is the active Administration Server. The Administration Server is a singleton application.

On IDMHOST2, the following installations have been performed:

An Oracle Directory Services Manager instance and an Oracle Directory Integration Platform instance have been installed in the WLS_ODS2 Managed Server. The RAC database has been configured in a JDBC multi data source to protect the instances from 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 Identity Federation instance has been installed in the WLS_OIF2 Managed Server. The RAC database has been configured in a JDBC multi data source to protect the instance from RAC node failure.

This Oracle Identity Federation instance and the one in the WLS_OIF1 Managed Server on IDMHOST1 are configured as the CLUSTER_OIF 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.

The directory tier includes the OIDHOST1 and OIDHOST2 computers.

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

On OIDHOST2, an Oracle Internet Directory instance and an Oracle Virtual Directory instance have been installed. Transparent Application Failover (TAF) is used to connect the Oracle Internet Directory instance with the 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 have been configured as a cluster. The Oracle Virtual Directory instances on OIDHOST1 and OIDHOST2 have also been configured as a cluster.

Note:

It is possible to configure 10g Oracle Single Sign-On and 10g Delegated Administration Services with 11g Oracle Internet Directory. See Section 8.3, "Setting up Multimaster Replication" for more information.

7.1.1 About the 11g Oracle Identity Management Products

Table 7-1 summarizes the 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 7-1 The 11g Identity and Access Management Product Suite

Product	Description
Oracle Internet Directory	Oracle Internet Directory is an LDAP Version 3-enabled service that enables fast retrieval and centralized management of information about dispersed users, network configuration, and other resources.
Oracle Virtual Directory	Oracle Virtual Directory is an LDAP Version 3-enabled service that 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 Directory Integration Platform	The Oracle Directory Integration Platform is a J2EE application that enables you to synchronize data between various directories and Oracle Internet Directory. Oracle Directory Integration Platform includes services and interfaces that allow you to deploy synchronization solutions with other enterprise repositories. It can also be used to provide Oracle Internet Directory interoperability with third party metadirectory solutions.
Oracle 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 Directory Services Manager	Oracle Directory Services Manager is a unified graphical user interface (GUI) for Oracle Virtual Directory and Oracle Internet Directory. Oracle Directory Services Manager simplifies the administration and configuration of Oracle Virtual Directory and Oracle Internet Directory by allowing 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.

7.2 Prerequisites for Oracle Identity Management High Availability Configuration

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

7.2.1 Oracle Home Requirement

The Oracle Home for the Identity Management components must be the same across all the 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.

7.2.2 Database Prerequisites

This section describes the database prerequisites.

Database versions supported

For Oracle Database 10g Release 2 (10.2.x), 10.2.0.4 and higher is supported.
For Oracle Database 11g Release 1 (11.1.x), 11.1.0.7 and higher is supported.

To determine the database version, execute this query:

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

7.2.3 Installing and Configuring the Database Repository

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

Oracle Clusterware

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

Automatic Storage Management

For 10g Release 2 (10.2), see Oracle Database Oracle Clusterware and Oracle Real Application Clusters Installation Guide.
For 11g Release 1 (11.1), see Oracle Clusterware Installation Guide.
When you run the installer, select the Configure Automatic Storage Management option in the Select Configuration page to create a separate Automatic Storage Management home.

Oracle Real Application Clusters

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

Many of the Oracle Fusion Middleware components require the existence of schemas in a database prior to installation. Oracle Fusion Middleware provides a tool, the Repository Creation Utility (RCU), to create the component schemas in an existing database. For high availability environments, these schemas must be created and loaded into a Real Application Clusters (RAC) database.

See the next section for information on using RCU to load the Oracle Identity Management schemas into a RAC database repository. This is a required step before you install the Oracle Identity Management components that are used in the high availability configurations described in this chapter.

7.2.4 Installing the Repository Creation Utility Software

The Repository Creation Utility (RCU) ships on its own CD as part of the Oracle Fusion Middleware 11g kit. You can use the RCU CD to run RCU and install schemas in a database repository.

Before you install any of the Oracle Identity Management components described in this chapter, run RCU to create the schemas used by Oracle Identity Management and Management Services into a RAC database. These schemas are required for the high availability Oracle Identity Management configurations described in this chapter. For detailed instructions about using RCU to install the required Oracle Internet Directory schemas, see Section 7.3.2.3.2, "Using RCU to Create Oracle Internet Directory Schemas in the Repository."

If you will be installing Oracle Identity Federation, you must also run RCU to create the schemas used by Oracle Identity Federation into a RAC database. For detailed instructions about using RCU to install the required Oracle Identity Federation schemas, see Section 7.7.2.3.1, "Using RCU to Create Oracle Identity Federation Schemas in the Repository."

When you install an Oracle Fusion Middleware product, RCU is installed in the Oracle home directory for that product and you will then be able to run RCU from that Oracle home.

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

7.2.5 Configuring the Database for Oracle Fusion Middleware 11g Metadata

This section describes how to configure the database for Oracle Fusion Middleware 11g metadata.

7.2.5.1 Initialization Parameters

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 method of changing the parameter value is to use a command similar to the following and then stop and restart the database to make the parameter take effect:

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

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

7.2.5.2 Database Examples in This Chapter

Table 7-2 shows the values used for database configuration examples in this chapter.

Table 7-2 Values Used for Database Configuration Examples in This Chapter

Parameter	Value
DB_NAME	idmdb
INSTANCE_NAMES	idmdb1, idmdb2
SERVICE_NAME	idmedg.mycompany.com

7.2.5.3 Database Services

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

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

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 => 'idmedg.mycompany.com',
NETWORK_NAME => 'idmedg.mycompany.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);

The EXECUTE DBMS_SERVICE command above must be entered on a single line to execute properly.

Add the service to the da tabase and assign it to the instances using srvctl:
```
prompt> srvctl add service -d idmdb -s idmedg -r idmdb1,idmdb2
```
Start the service using srvctl:
```
prompt> srvctl start service -d idmdb -s  idmedg
```
Note:
For more information about the SRVCTL command, see the Oracle Real Application Clusters Administration and Deployment Guide.

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

prompt> sqlplus "sys/password as sysdba"

SQL> EXECUTE DBMS_SERVICE.MODIFY_SERVICE
(SERVICE_NAME => 'idmedg.mycompany.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);

The EXECUTE DBMS_SERVICE command above must be entered on a single line to execute properly.

Note:

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

7.2.5.4 Verifying Transparent Application Failover (TAF)

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

After the Oracle Internet Directory process has been started, 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

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

7.2.5.5.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 host name:

Clients access services using the virtual host name (instead of using actual host names). The load balancer can then load balance requests to the servers in the pool.
Port translation configuration
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 allow configuration of multiple virtual servers. For each virtual server, the load balancer should allow 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

It is highly recommended that you configure the load balancer virtual server to return immediately to the calling client when the back-end services to which it forwards traffic 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.
SSL acceleration

This feature is recommended, but not required.

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

Table 7-3 Virtual Server Names for the External Load Balancer

Component	Virtual Server Name
Oracle Internet Directory	oid.mycompany.com
Oracle Virtual Directory	ovd.mycompany.com
Oracle Identity Federation	oif.mycompany.com
WebLogic Server Administration Console	admin.mycompany.com
Oracle Enterprise Manager Fusion Middleware Control	admin.mycompany.com
Oracle Directory Services Manager Console	admin.mycompany.com

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

oid.mycompa ny.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.mycompany.com:636 for SSL and oid.mycompany.com:389 for non-SSL.

Note:

Oracle recommends that you configure the same LDAP port for SSL connections on the virtual server and on the computers on which Oracle Internet Directory is installed.

This is a requirement for most 10g Oracle Fusion Middleware products that need to use Oracle Internet Directory via the load balancer.

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

ovd.mycomp any.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.mycompany.com:7501 for SSL and ovd.mycompany.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.mycom pany.com

This virtual server acts as the access point for all HTTP traffic to the Oracle Identity Federation servers in the application tier. Traffic to both the SSL and non-SSL port is configured. The clients access this service using the address oif.mycompany.com:4444 for SSL and ovd.mycompany.com:7499 for non-SSL.

Monitor the heartbeat of the Oracle Internet Federation Server processes on OIFHOST1 and OIFHOST2. If an Oracle Internet Federation Server process stops on OIFHOST1 or OIFHOST2, or if either host OIFHOST1 or OIFHOST2 is down, the load balancer must continue to route traffic to the surviving computer.

admin.myc ompany.com

This virtual server acts as the access point for all internal HTTP traffic that gets directed to the administration services. The incoming traffic from clients is non-SSL enabled. Thus, the clients access this service using the address admin.mycompany.com:80 and in turn forward these to ports 7777 on WEBHOST1 and WEBHOST2. The services accessed on this virtual host include the WebLogic Administration Server Console, Oracle Enterprise Manager and Oracle Directory Services Manager.

In addition, 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.

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

7.3.1 Oracle Internet Directory Component Architecture

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

The Oracle directory replication server uses LDAP to communicate with an Oracle directory (LDAP) server instance. To communicate with the database, all components use OCI/Oracle Net Services. Oracle Directory Services Manager and the command-line tools communicate with the Oracle directory servers over LDAP.

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

Figure 7-2 Oracle Internet Directory in a Non-High Availability Architecture

Description of "Figure 7-2 Oracle Internet Directory in a Non-High Availability Architecture"

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

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

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

The Oracle directory server non-SSL port (389 for this topology)
The Oracle directory server SSL-enabled port (636 for this topology)
The OID Monitor

LDAP is used for connections between the directory server and:

Oracle Directory Services Manager
Oracle directory replication server

The Oracle directory server instance and the Oracle directory replication server connect to OID Monitor by way of the operating system.

As shown in Figure 7-2, an Oracle Internet Directory node includes the following major elements:

Table 7-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 about Oracle Internet Directory replication, refer to Chapter 8, "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.

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

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

7.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 Stop ping 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:

Upon receiving the start command, OPMN issues an oidmon start command with appropriate arguments, as specified in the opmn.xml file.
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:

Upon receiving the stop command, OPMN issues an oidmon stop command.
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.

7.3.1.1.3 Request Flow

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

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

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

cn=componentname,cn=osdldapd,cn=subconfigsubentry

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

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

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

7.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 7-5 shows Oracle Internet Directory processes and the log file name and location for the process.

Table 7-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 the log files to troubleshoot Oracle Internet Directory issues, see Section 7.3.6, "Troubleshooting Oracle Internet Directory High Availability".

7.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 7.3.2.3, "Oracle Internet Directory Prerequisites" for prerequisites and Section 7.3.3, "Oracle Internet Directory High Availability Configuration Steps" for specific steps for setting up the two-node Cluster Configuration.

7.3.2.1 Oracle Internet Directory High Availability Architecture

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

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

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

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

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

7.3.2.1.1 Starting and S topping the Cluster

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

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

7.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 Oracle Internet Directory server and updates the database repository about configuration changes. OIDMON and other Oracle Internet Directory servers pull the changes from the database repository. In this way, any change made at a cluster member level is propagated to every Oracle Internet Directory server in the cluster.

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

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

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

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

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

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

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

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

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

7.3.2.2 Protection from Failures and Expected Behavior

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

7.3.2.2.1 Oracle Internet Directory Process Failure

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

OIDMON is monitored by OPMN. If OIDMON goes down, OPMN restarts OIDMON.

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

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

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

7.3.2.2.2 Expected Client Application Behavior When Failure Occurs

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

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

7.3.2.2.3 External Dependency Failure

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

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

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

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

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

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

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

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

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

7.3.2.3 Oracle Internet Directory Prerequisites

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

7.3.2.3.1 Synchronizing the Time on Oracle Internet Directory Nodes

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

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

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

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

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

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

The Repository Creation Utility (RCU) ships on its own CD as part of the Oracle Fusion Middleware 11g kit.

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

Issue this command:

prompt> RCU_HOME/bin/rcu &
On the Welcome screen, click Next.
On the Create Repository screen, select the Create operation to load component schemas into an existing database.

Click Next.
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 a 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: idmedg.mycompany.com

Username: SYS

Password: The SYS user password

Role: SYSDBA

Click Next.
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.
On the Schema Passwords screen, enter the passwords for the main and additional (auxiliary) schema users.

Click Next.
On the Map Tablespaces screen, select the tablespaces for the components.
On the Summary screen, click Create.
On the Completion Summary screen, click Close.

7.3.2.3.3 Load Balancer Virtual Server Names for Oracle Internet Directory

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

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

7.3.3 Oracle Internet Directory High Availability Configuration Steps

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

The standalone mode should be chosen for deployments where Oracle Internet Directory will be managed entirely using command line tools, and where Oracle Enterprise Manager Fusion Middleware Control and Oracle Directory Services Manager are not deemed mandatory. Later, if desired, the standalone Oracle Internet Directory instances can be registered with a remote Oracle WebLogic Server domain using opmnctl commands. Oracle Enterprise Manager Fusion Middleware Control and Oracle Directory Services Manager can be used to manage Oracle Internet Directory instances that are configured with an Oracle WebLogic Server domain.

It is recommended that Oracle Internet Directory be set up in a clustered deployment, where the clustered Oracle Internet Directory instances access the same RAC database repository.

7.3.3.1 Configuring Oracle Internet Directory Without a WebLogic Domain

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

7.3.3.1.1 Installing Oracle Internet Directory on OIDHOST1

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

Ensure that the system, patch, kernel and other requirements are met. These are listed in the Oracle Fusion Middleware Installation Guide for Oracle Identity Management in the Oracle Fusion Middleware documentation library for the platform and version you are using.
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"
```
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.
Copy the staticports.ini file from the Disk1/stage/Response directory to a temporary directory.
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 Oracle Internet Directory
Oracle Internet Directory port = 389
# The SSL port for Oracle Internet Directory
Oracle Internet Directory (SSL) port = 636
```
Start the Oracle Identity Management 11g installer as follows:

On UNIX, issue this command: runInstaller

On Windows, double-click setup.exe

The runInstaller and setup.exe files are in the ../install/platform directory, where platform is a platform such as Linux or Win32.

This displays the Specify Oracle Inventory screen.
On the Specify Inventory Directory screen, enter values for the Oracle Inventory Directory and the Operating System Group Name. For example:

Specify the Inventory Directory: /u01/app/oraInventory

Operating System Group Name: oinstall

A dialog box appears with the following message:

"Certain actions need to be performed with root privileges before the install can continue. Please execute the script /u01/app/oraInventory/createCentralInventory.sh now from another window and then press "Ok" to continue the install. If you do not have the root privileges and wish to continue the install select the "Continue installation with local inventory" option"

Log in as root and run the "/u01/app/oraInventory/createCentralInventory.sh"

This sets the required permissions for the Oracle Inventory Directory and then brings up the Welcome screen.
Note:
The Oracle Inventory screen is not shown if an Oracle product was previously installed on the host. If the Oracle Inventory screen is not displayed for this installation, make sure to check and see:
1. If the /etc/oraInst.loc file exists
2. If the file exists, the Inventory directory listed is valid
3. The user performing the installation has write permissions for the Inventory directory
On the Welcome screen, click Next.
On the Select Installation Type screen, select Install and Configure and then click Next.
On the Prerequisite Checks screen, the installer completes the prerequisite check. If any fail, fix them and restart your installation.

Click Next.
On the Select Domain screen, select Configure without a Domain and then click Next.
On the Specify Installation Location screen, specify the following values:
- Oracle Home Location:
```
/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.
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.
On the Configure Components screen, select Oracle Internet Directory, deselect all the other components, and click Next.
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.
On the Specify Schema Database screen, select Use Existing Schema and specify the following values:
- Connect String:
```
infradbhost1-vip.mycompany.com:1521:idmdb1^infradbhost2-vip.mycompany.com:1521:idmdb2@idmedg.mycompany.com
```
  Note:
  The 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 RAC instances to be up. If one 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 RAC instance, and the service name provided must be configured for all the specified RAC instances.
  
  Any incorrect information entered in the RAC database connect string has to be corrected manually after the installation.
- User Name: ODS
- Password: ******
Click Next.
On the Create Oracle Internet Directory screen, specify the Realm and enter the Administrator (cn=orcladmin) password and click Next.
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.
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.
On the Configuration screen, multiple configuration assistants are launched in succession; this process can be lengthy. When it completes, click Next.
On the Installation Complete screen, click Finish to confirm your choice to exit.

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

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

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

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

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

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

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

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

7.3.3.1.3 Installing Oracle Internet Directory on OIDHOST2

Make sure that the Oracle Internet Directory repository is running and then follow these steps to install the Oracle Internet Directory instance on OIDHOST2:

Note:

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

Ensure that the system, patch, kernel and other requirements are met. These are listed in the Oracle Fusion Middleware Installation Guide for Oracle Identity Management in the Oracle Fusion Middleware documentation library for the platform and version you are using.
On OIDHOST1, ports 389 and 636 were used for Oracle Internet Directory. The same ports should be used for the Oracle Internet Directory instance on OIDHOST2. Therefore, ensure that ports 389 and 636 are not in use by any service on OIDHOST2 by issuing these commands for the operating system you are using. If a port is not in use, no output is returned from the command.

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"
```
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.
Copy the staticports.ini file from the Disk1/stage/Response directory to a temporary directory.
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 Oracle Internet Directory
Oracle Internet Directory port = 389
# The SSL port for Oracle Internet Directory
Oracle Internet Directory (SSL) port = 636
```
Start the Oracle Identity Management 11g Installer as follows:

On UNIX, issue this command: runInstaller

On Windows, double-click setup.exe

The runInstaller and setup.exe files are in the ../install/platform directory, where platform is a platform such as Linux or Win32.

This displays the Specify Oracle Inventory screen.
On the Specify Inventory Directory screen, enter values for the Oracle Inventory Directory and the Operating System Group Name. For example:

Specify the Inventory Directory: /u01/app/oraInventory

Operating System Group Name: oinstall

A dialog box appears with the following message:

"Certain actions need to be performed with root privileges before the install can continue. Please execute the script /u01/app/oraInventory/createCentralInventory.sh now from another window and then press "Ok" to continue the install. If you do not have the root privileges and wish to continue the install select the "Continue installation with local inventory" option"

Log in as root and run the "/u01/app/oraInventory/createCentralInventory.sh"

This sets the required permissions for the Oracle Inventory Directory and then brings up the Welcome screen.
Note:
The Oracle Inventory screen is not shown if an Oracle product was previously installed on the host. If the Oracle Inventory screen is not displayed for this installation, make sure to check and see:
1. If the /etc/oraInst.loc file exists
2. If the file exists, the Inventory directory listed is valid
3. The user performing the installation has write permissions for the Inventory directory
On the Welcome screen, click Next.
On the Select Installation Type screen, select Install and Configure and then click Next.
On the Prerequisite Checks screen, the installer completes the prerequisite check. If any fail, fix them and restart your installation.

Click Next.
On the Select Domain screen, select Configure without a Domain and then click Next.
On the Specify Installation Location screen, specify the following values:
- Oracle Home Location:
```
/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.
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.
On the Configure Components screen, select Oracle Internet Directory, deselect all the other components, and click Next.
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.
On the Specify Schema Database screen, select Use Existing Schema and specify the following values.
- Connect String:
```
infradbhost1-vip.mycompany.com:1521:idmdb1^infradbhost2-vip.mycompany.com:1521:idmdb2@idmedg.mycompany.com
```
  Note:
  The 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 RAC instances to be up. If one 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 RAC instance, and the service name provided must be configured for all the specified RAC instances.
  
  Any incorrect information entered in the RAC database connect string has to be corrected manually after the installation.
- User Name: ODS
- Password: ******
Click Next.
The ODS Schema in use message appears. The ODS schema chosen is already being used by the existing Oracle Internet Directory instance. Therefore, the new Oracle Internet Directory instance being configured would reuse the same schema.

Choose Yes to continue.
On the Specify OID Administrator Password screen, specify the OID Administrator password and click Next.
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.
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.
On the Configuration screen, multiple configuration assistants are launched in succession; this process can be lengthy. When it completes, click Next.
On the Installation Complete screen, click Finish to confirm your choice to exit.

7.3.3.1.4 Registering Oracle Internet Directory with a WebLogic Domain

If you want to manage an Oracle Internet Directory component with Oracle Enterprise Manager Fusion Middleware Control, you must register the component and the Oracle Fusion Middleware instance that contains it with an 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. If an Oracle Fusion Middleware instance was not previously registered with a WebLogic domain, you can register it by using opmnctl registerinstance.

Before using the opmnctl registerinstance command to register an Oracle Internet Directory instance with an Oracle WebLogic Server domain, make sure that the WebLogic Server is already installed.

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

opmnctl registerinstance -adminHost WLSHostName -adminPort WLSPort
-adminUsername adminUserName

For example:

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

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

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

7.3.3.2 Configuring Oracle Internet Directory With a WebLogic Domain

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

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

7.3.3.2.1 Installing Oracle WebLogic Server

On OIDHOST1, start the Oracle WebLogic Server installation by running the installer executable file.

Start the Oracle WebLogic Server installer as follows:

On UNIX (Linux in the following example):
```
./wls1032_linux32.bin
```
On Windows:
```
wls1032_win32.exe
```

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

On the Welcome screen, click Next.
On the Choose Middleware Home Directory screen, choose a directory on your computer into which the Oracle WebLogic software is to be installed.

For the Middleware Home Directory, specify this value:
```
/u01/app/oracle/product/fmw
```
Click Next.
On the Register for Security Updates screen, enter your "My Oracle Support" User Name and Password.
On the Choose Install Type screen, the installation program displays a window in which you are prompted to indicate whether you wish to perform a complete or a custom installation.

Choose Typical or Custom.

Click Next.
On the Choose Product Installation Directories screen, specify the following value:

WebLogic Server:
```
/u01/app/oracle/product/fmw/wlserver_10.3
```
Click Next.
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.
On the Installation Complete screen, deselect the Run Quickstart checkbox.

Click Done.

7.3.3.2.2 Installing Oracle Internet Directory on OIDHOST1

The schema database must be running before you perform this task. Also make sure that RCU has been used to seed the ODS database schema. Then follow these steps to install the 11g Oracle Internet Directory on OIDHOST1:

Ensure that the system, patch, kernel and other requirements are met. These are listed in the Oracle Fusion Middleware Installation Guide for Oracle Identity Management in the Oracle Fusion Middleware documentation library for the platform and version you are using.
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"
```
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.
Copy the staticports.ini file from the Disk1/stage/Response directory to a temporary directory.
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 Internet Directory):
```
# The non-SSL port for Oracle Internet Directory
Oracle Internet Directory port = 389
# The SSL port for Oracle Internet Directory
Oracle Internet Directory (SSL) port = 636
```
Start the Oracle Identity Management 11g Installer as follows:

On UNIX, issue this command: runInstaller

On Windows, double-click setup.exe

The runInstaller and setup.exe files are in the ../install/platform directory, where platform is a platform such as Linux or Win32.

This displays the Specify Oracle Inventory screen.
On the Specify Inventory Directory screen, enter values for the Oracle Inventory Directory and the Operating System Group Name. For example:

Specify the Inventory Directory: /u01/app/oraInventory

Operating System Group Name: oinstall

A dialog box appears with the following message:

"Certain actions need to be performed with root privileges before the install can continue. Please execute the script /u01/app/oraInventory/createCentralInventory.sh now from another window and then press "Ok" to continue the install. If you do not have the root privileges and wish to continue the install select the "Continue installation with local inventory" option"

Log in as root and run the "/u01/app/oraInventory/createCentralInventory.sh"

This sets the required permissions for the Oracle Inventory Directory and then brings up the Welcome screen.
Note:
The Oracle Inventory screen is not shown if an Oracle product was previously installed on the host. If the Oracle Inventory screen is not displayed for this installation, make sure to check and see:
1. If the /etc/oraInst.loc file exists
2. If the file exists, the Inventory directory listed is valid
3. The user performing the installation has write permissions for the Inventory directory
On the Welcome screen, click Next.
On the Select Installation Type screen, select Install and Configure and then click Next.
On the Prerequisite Checks screen, the installer completes the prerequisite check. If any fail, fix them and restart the installation.

Click Next.
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
On the Specify Installation Location screen, specify the following values:
- Oracle Middleware Home Location:
```
/u01/app/oracle/product/fmw
```
- Oracle Home Directory: idm
- Oracle Instance Location:
```
/u01/app/oracle/admin/oid_inst1
```
- Oracle Instance Name: oid_inst1
  
  Note:
  Ensure that the Oracle Home directory path for OIDHOST1 is the same as the Oracle Home directory path for OIDHOST2. For example, if the Oracle Home directory path for OIDHOST1 is:
  /u01/app/oracle/product/fmw/idm
  
  then the Oracle Home directory path for OIDHOST2 must be:
  
  /u01/app/oracle/product/fmw/idm
Click Next.
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.
On the Configure Components screen, select Oracle Internet Directory & Management Components.

Click Next.
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).
On the Specify Schema Database screen, select Use Existing Schema and specify the following values:
- Connect String:
```
infradbhost1-vip.mycompany.com:1521:idmdb1^infradbhost2-vip.mycompany.com:1521:idmdb2@idmedg.mycompany.com
```
  Note:
  The 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 RAC instances to be up. If one 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 RAC instance, and the service name provided must be configured for all the specified RAC instances.
  
  Any incorrect information entered in the RAC database connect string has to be corrected manually after the installation.
- User Name: ODS
- Password: ******
Click Next.
On the Configure OID screen, specify the Realm and enter the Administrator (cn=orcladmin) password and click Next.
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.
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.
On the Configuration screen, multiple configuration assistants are launched in succession; this process can be lengthy. When it completes, click Next.
On the Installation Complete screen, click Finish to confirm your choice to exit.

Note:
For information on the Oracle Internet Directory component names assigned by Oracle Identity Management 11g Installer, refer to Section 7.3.3.1.2, "Oracle Internet Directory Component Names Assigned by Oracle Identity Management Installer."

7.3.3.2.3 Creating boot.properties for the Administration Server on OIDHOST1

This section describes how to create a boot.properties file for the Administration Server on OIDHOST1. 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:

On OIDHOST1, go the following directory:

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

For example:

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

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.
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.
Start the Administration Server on OIDHOST1 using the startWebLogic.sh script located under the MW_HOME/user_projects/domains/domainName/bin directory.
Validate that the changes were successful by opening a web browser and accessing the following pages:
- WebLogic Server Administration Console at:
```
http://oidhost1.mycompany.com:7001/console
```
- Oracle Enterprise Manager Fusion Middleware Control at:
```
http://oidhost1.mycompany.com:7001/em
```
Log into these consoles using the weblogic user credentials.

7.3.3.2.4 Installing Oracle Internet Directory on OIDHOST2

Make sure that the Oracle Internet Directory repository is running and then follow these steps to install the Oracle Internet Directory instance on OIDHOST2:

Ensure that the system, patch, kernel and other requirements are met. These are listed in the Oracle Fusion Middleware Installation Guide for Oracle Identity Management in the Oracle Fusion Middleware documentation library for the platform and version you are using.
On OIDHOST1, ports 389 and 636 were used for Oracle Internet Directory. The same ports should be used for the Oracle Internet Directory instance on OIDHOST2. Therefore, ensure that ports 389 and 636 are not in use by any service on OIDHOST2 by issuing these commands for the operating system you are using. If a port is not in use, no output is returned from the command.

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"
```
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.
Copy the staticports.ini file from the Disk1/stage/Response directory to a temporary directory.
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 Internet Directory):
```
# The non-SSL port for Oracle Internet Directory
Oracle Internet Directory port = 389
# The SSL port for Oracle Internet Directory
Oracle Internet Directory (SSL) port = 636
```
Start the Oracle Identity Management 11g Installer as follows:

On UNIX, issue this command: runInstaller

On Windows, double-click setup.exe

The runInstaller and setup.exe files are in the ../install/platform directory, where platform is a platform such as Linux or Win32.

This displays the Specify Oracle Inventory screen.
On the Specify Inventory Directory screen, enter values for the Oracle Inventory Directory and the Operating System Group Name. For example:

Specify the Inventory Directory: /u01/app/oraInventory

Operating System Group Name: oinstall

A dialog box appears with the following message:

"Certain actions need to be performed with root privileges before the install can continue. Please execute the script /u01/app/oraInventory/createCentralInventory.sh now from another window and then press "Ok" to continue the install. If you do not have the root privileges and wish to continue the install select the "Continue installation with local inventory" option"

Log in as root and run the "/u01/app/oraInventory/createCentralInventory.sh"

This sets the required permissions for the Oracle Inventory Directory and then brings up the Welcome screen.
Note:
The Oracle Inventory screen is not shown if an Oracle product was previously installed on the host. If the Oracle Inventory screen is not displayed for this installation, make sure to check and see:
1. If the /etc/oraInst.loc file exists
2. If the file exists, the Inventory directory listed is valid
3. The user performing the installation has write permissions for the Inventory directory
On the Welcome screen, click Next.
On the Select Installation Type screen, select Install and Configure and then click Next.
On the Prerequisite Checks screen, the installer completes the prerequisite check. If any fail, fix them and restart the installation.

Click Next.
On the Select Domain screen, select Extend Existing Domain and specify the following values.
- HostName: idmhost1.mycompany.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>
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/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.
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.
On the Configure Components screen, select Oracle Internet Directory and click Next.
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.
On the Specify Schema Database screen, select Use Existing Schema and specify the following values:
- Connect String:
```
infradbhost1-vip.mycompany.com:1521:idmdb1^infradbhost2-vip.mycompany.com:1521:idmdb2@idmedg.mycompany.com
```
  Note:
  The 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 RAC instances to be up. If one 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 RAC instance, and the service name provided must be configured for all the specified RAC instances.
  
  Any incorrect information entered in the RAC database connect string has to be corrected manually after the installation.
- User Name: ODS
- Password: ******
Click Next.
The ODS Schema in use message appears. The ODS schema chosen is already being used by the existing Oracle Internet Directory instance. Therefore, the new Oracle Internet Directory instance being configured would reuse the same schema.

Choose Yes to continue.
On the Specify OID Admin Password screen, specify the Oracle Internet Directory Administrator password and click Next.
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.
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.
On the Configuration screen, multiple configuration assistants are launched in succession; this process can be lengthy. When it completes, click Next.
On the Installation Complete screen, click Finish to confirm your choice to exit.

7.3.4 Validating Oracle Internet Directory High Availability

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

Note:

See the "Configuring Your Environment" section of Oracle Fusion Middleware User 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.mycompany.com -p 389 -D "cn=orcladmin" -q
ldapbind -h oidhost2.mycompany.com -p 389 -D "cn=orcladmin" -q
ldapbind -h oid.mycompany.com -p 389 -D "cn=orcladmin" -q

Note:

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

For SSL:

ldapbind -h oidhost1.mycompany.com -p 636 -D "cn=orcladmin" -q -U 1
ldapbind -h oidhost2.mycompany.com -p 636 -D "cn=orcladmin" -q -U 1
ldapbind -h oid.mycompany.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 User Reference for Oracle Identity Management.

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

WebLogic Server Administration Console:

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

Oracle Enterprise Manager Fusion Middleware Console:

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

7.3.5 Oracle Internet Directory Failover and Expected Behavior

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

7.3.5.1 Performing an Oracle Internet Directory Failover

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

On OIDHOST1, use the opmnctl command to stop the Oracle Internet Directory instance:
```
ORACLE_INSTANCE/bin/opmnctl stopproc ias-component=oid1
```
On OIDHOST2, check the status of Oracle Internet Directory using the load balancing router:

Note:
See the "Configuring Your Environment" section of Oracle Fusion Middleware User Reference for Oracle Identity Management for a list of the environment variables you must set before using the ldapbind command.
```
ldapbind -h oid.mycompany.com -p 389 -D "cn=orcladmin" -q
```
Note:
The -q option above prompts the user for a password. LDAP tools have been modified to disable the options -w password and -P password when the environment variable LDAP_PASSWORD_PROMPTONLY is set to TRUE or 1. Use this feature whenever possible.

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

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

On OIDHOST2, use the opmnctl command to stop the Oracle Internet Directory instance:
```
ORACLE_INSTANCE/bin/opmnctl stopproc ias-component=oid1
```
On OIDHOST1, check the status of Oracle Internet Directory using the load balancing router:
```
ldapbind -h oid.mycompany.com -p 389 -D "cn=orcladmin" -q
```

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

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

7.3.5.2 Performing a RAC Failover

Follow these steps to perform a RAC failover:

Use the srvctl command to stop a database instance:

srvctl stop instance -d db_unique_name -i inst_name_list

Use the srvctl command to check the status of the database:
```
srvctl status database -d db_unique_name -v
```
Check the status of Oracle Internet Directory:

Note:
See the "Configuring Your Environment" section of Oracle Fusion Middleware User Reference for Oracle Identity Management for a list of the environment variables you must set before using the ldapbind command.
```
ldapbind -h oid_host -p 389 -D "cn=orcladmin" -q
ldapbind -h oid_host -p 389 -D "cn=orcladmin" -q
ldapbind -h oid.mycompany.com -p 389 -D "cn=orcladmin" -q
```
Note:
The -q option above prompts the user for a password. LDAP tools have been modified to disable the options -w password and -P password when the environment variable LDAP_PASSWORD_PROMPTONLY is set to TRUE or 1. Use this feature whenever possible.

Use the srvctl command to start the database instance:

srvctl start instance -d db_unique_name -i inst_name_list

7.3.6 Troubleshooting Oracle Internet Directory High Availability

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

Log files for Oracle Internet Directory are found in the following directory:
```
ORACLE_INSTANCE/diagnostics/log/OID
```
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.us.oracle.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 Oracle Internet Directory, see Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory.

7.3.7 Additional Oracle Inter net Directory High Availability Issues

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

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

You can change the Oracle Internet Directory database schema password (that is, the password of the ODS user in the database) using the Oracle Internet Directory Database Password Utility (oidpasswd) from any of the Oracle Internet Directory 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 Oracle Internet Directory node.

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

oidpasswd connect=database-connection-string change_oiddb_pwd=true

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

oidpasswd connect=database-connection-string create_wallet=true

If you change the ODS password on one Oracle RAC node by using the 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 the Oracle RAC nodes, the Oracle Internet Directory instance on the second node will not be able to start on the other nodes. You will see this error in the OIDMON log file:

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

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

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

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

Figure 7-4 shows Oracle Virtual Directory in a non-high availability architecture.

Figure 7-4 Oracle Virtual Directory in a Non-High Availability Architecture

Description of "Figure 7-4 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.

7.4.1.1 Oracle Virtual Directory Runtime Considerations

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

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

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

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

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

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

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

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

7.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:
For information on configuring 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. The procedure described in that manual can be used 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.

7.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 7.4.6, "Troubleshooting Oracle Virtual Directory High Availability".

7.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 7.4.2.2, "Oracle Virtual Directory Prerequisites" for prerequisites and Section 7.4.3, "Oracle Virtual Directory High Availability Configuration Steps" for specific steps for setting up the two-node cluster.

7.4.2.1 Oracle Virtual Directory High Availability Architecture

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

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

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

Figure 7-5 shows Oracle Virtual Directory in the directory tier in a high availability architecture. The two-node cluster is set up at installation time. The load balancing router routes requests to the two Oracle Virtual Directory instances that are clustered on OVDHOST1 and OVDHOST2. Fast Connection Failover (FCF) is used for notification when a 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. See the "Cloning Oracle Fusion Middleware" chapter in Oracle Fusion Middleware Administrator's Guide for more information about cloning.

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.

7.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 simply 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 allow 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 allow it to spread load and manage failures between its proxied LDAP directory sources.

Oracle Virtual Directory's virtual directory tree capability allows 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 (RAC). See Section 4.1.5, "JDBC Clients" for more information about using Oracle Virtual Directory with RAC.

Oracle Virtual Directory Routing also provides load balancing capabilities. Routing allows 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 7.4.6, "Troubleshooting Oracle Virtual Directory High Availability".

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

7.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 7.2.5.5, "Configuring Virtual Server Names and Ports for the Load Balancer" for details.

7.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 7.8, "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 RAC database repository or LDAP repository.

7.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 7.4.3.1.1, "Installing Oracle Virtual Directory on OVDHOST1" and Section 7.4.3.1.2, "Installing Oracle Virtual Directory on OVDHOST2" are installed using the Configure without a Domain installation option.

7.4.3.1.1 Installing Oracle Virtual Directory on OVDHOST1

Make sure that the schema database is running, then follow these steps to install the Oracle Virtual Directory instance on OVDHOST1:

Ensure that the system, patch, kernel and other requirements are met. These are listed in Oracle Fusion Middleware Installation Guide for Oracle Identity Management in the Oracle Fusion Middleware documentation library for the platform and version you are using.
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"
```
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.
Copy the staticports.ini file from the Disk1/stage/Response directory to a temporary directory.
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 port for Oracle Virtual Directory
Oracle Virtual Directory port = 6501
# The SSL port for Oracle Virtual Directory
Oracle Virtual Directory (SSL) port = 7501
```
Start the Oracle Identity Management 11g Installer as follows:

On UNIX, issue this command: runInstaller

On Windows, double-click setup.exe

The runInstaller and setup.exe files are in the ../install/platform directory, where platform is a platform such as Linux or Win32.

This displays the Specify Oracle Inventory screen.
On the Specify Inventory Directory screen, enter values for the Oracle Inventory Directory and the Operating System Group Name. For example:

Specify the Inventory Directory: /u01/app/oraInventory

Operating System Group Name: oinstall

A dialog box appears with the following message:

"Certain actions need to be performed with root privileges before the install can continue. Please execute the script /u01/app/oraInventory/createCentralInventory.sh now from another window and then press "Ok" to continue the install. If you do not have the root privileges and wish to continue the install select the "Continue installation with local inventory" option"

Log in as root and run the "/u01/app/oraInventory/createCentralInventory.sh"

This sets the required permissions for the Oracle Inventory Directory and then brings up the Welcome screen.
Note:
The Oracle Inventory screen is not shown if an Oracle product was previously installed on the host. If the Oracle Inventory screen is not displayed for this installation, make sure to check and see:
1. If the /etc/oraInst.loc file exists
2. If the file exists, the Inventory directory listed is valid
3. The user performing the installation has write permissions for the Inventory directory
On the Welcome screen, click Next.
On the Select Installation Type screen, select Install and Configure and then click Next.
On the Prerequisite Checks screen, the installer completes the prerequisite check. If any fail, fix them and restart your installation.

Click Next.
On the Select Domain screen, select Configure without a Domain and then click Next.
On the Specify Installation Location screen, specify the following values:
- Oracle Home Location:
```
/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.
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.
On the Configure Components screen, select Oracle Virtual Directory and click Next.
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.
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.
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.
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.
On the Configuration screen, multiple configuration assistants are launched in succession; this process can be lengthy. When it completes, click Next.
On the Installation Complete screen, click Finish to confirm your choice to exit.

7.4.3.1.2 Installing Oracle Virtual Directory on OVDHOST2

Make sure that the schema database is running, then follow these steps to install the Oracle Virtual Directory instance on OVDHOST2:

Note:

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

Ensure that the system, patch, kernel and other requirements are met. These are listed in Oracle Fusion Middleware Installation Guide for Oracle Identity Management in the Oracle Fusion Middleware documentation library for the platform and version you are using.
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"
```
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.
Copy the staticports.ini file from the Disk1/stage/Response directory to a temporary directory.
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 port for Oracle Virtual Directory
Oracle Virtual Directory port = 6501
# The SSL port for Oracle Virtual Directory
Oracle Virtual Directory (SSL) port = 7501
```
Start the Oracle Identity Management 11g Installer as follows:

On UNIX, issue this command: runInstaller

On Windows, double-click setup.exe

The runInstaller and setup.exe files are in the ../install/platform directory, where platform is a platform such as Linux or Win32.

This displays the Specify Oracle Inventory screen.
On the Specify Inventory Directory screen, enter values for the Oracle Inventory Directory and the Operating System Group Name. For example:

Specify the Inventory Directory: /u01/app/oraInventory

Operating System Group Name: oinstall

A dialog box appears with the following message:

"Certain actions need to be performed with root privileges before the install can continue. Please execute the script /u01/app/oraInventory/createCentralInventory.sh now from another window and then press "Ok" to continue the install. If you do not have the root privileges and wish to continue the install select the "Continue installation with local inventory" option"

Log in as root and run the "/u01/app/oraInventory/createCentralInventory.sh"

This sets the required permissions for the Oracle Inventory Directory and then brings up the Welcome screen.
Note:
The Oracle Inventory screen is not shown if an Oracle product was previously installed on the host. If the Oracle Inventory screen is not displayed for this installation, make sure to check and see:
1. If the /etc/oraInst.loc file exists
2. If the file exists, the Inventory directory listed is valid
3. The user performing the installation has write permissions for the Inventory directory
On the Welcome screen, click Next.
On the Select Installation Type screen, select Install and Configure and then click Next.
On the Prerequisite Checks screen, the installer completes the prerequisite check. If any fail, fix them and restart your installation.

Click Next.
On the Select Domain screen, select Configure without a Domain and then click Next.
On the Specify Installation Location screen, specify the following values:
- Oracle Home Location:
```
/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.
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.
On the Configure Components screen, select Oracle Virtual Directory and click Next.
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.
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.
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.
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.
On the Configuration screen, multiple configuration assistants are launched in succession; this process can be lengthy. When it completes, click Next.
On the Installation Complete screen, click Finish to confirm your choice to exit.

7.4.3.1.3 Registering Oracle Virtual Directory with a WebLogic Domain

It is recommended that you manage your Oracle Virtual Directory component with Oracle Enterprise Manager Fusion Middleware Control. To be able to manage Oracle Virtual Directory using 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. If an Oracle Fusion Middleware instance was not previously registered with a WebLogic domain, you can register it by using opmnctl registerinstance.

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

opmnctl registerinstance -adminHost WLSHostName -adminPort WLSPort
-adminUsername adminUserName

For example:

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

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

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

7.4.3.2 Configuring Oracle Virtual Directory With a WebLogic Domain

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

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

7.4.3.2.1 Installing Oracle WebLogic Server

On OVDHOST1, start the Oracle WebLogic Server installation by running the installer executable file.

Start the Oracle WebLogic Server installer as follows:

On UNIX (Linux in the following example):
```
./wls1032_linux32.bin
```
On Windows:
```
wls1032_win32.exe
```

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

On the Welcome screen, click Next.
On the Choose Middleware Home Directory screen, choose a directory on your computer into which the Oracle WebLogic software is to be installed.

For the Middleware Home Directory, specify this value:
```
/u01/app/oracle/product/fmw
```
Click Next.
On the Register for Security Updates screen, enter your "My Oracle Support" User Name and Password.
On the Choose Install Type screen, t.he installation program displays a window in which you are prompted to indicate whether you wish to perform a complete or a custom installation

Choose Typical or Custom.

Click Next.
On the Choose Product Installation Directories screen, specify the following value:

WebLogic Server:
```
/u01/app/oracle/product/fmw/wlserver_10.3
```
Click Next.
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.
On the Installation Complete screen, deselect the Run Quickstart checkbox.

Click Done.

7.4.3.2.2 Installing the First Oracle Virtual Directory

The schema database must be running before you perform this task. Follow these steps to install the Oracle Virtual Directory instance on OVDHOST1:

Ensure that the system, patch, kernel and other requirements are met. These are listed in Oracle Fusion Middleware Installation Guide for Oracle Identity Management in the Oracle Fusion Middleware documentation library for the platform and version you are using.
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"
```
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.
Copy the staticports.ini file from the Disk1/stage/Response directory to a temporary directory.
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 port for Oracle Virtual Directory
Oracle Virtual Directory port = 6501
# The SSL port for Oracle Virtual Directory
Oracle Virtual Directory (SSL) port = 7501
```
Start the Oracle Identity Management 11g Installer as follows:

On UNIX, issue this command: runInstaller

On Windows, double-click setup.exe

The runInstaller and setup.exe files are in the ../install/platform directory, where platform is a platform such as Linux or Win32.

This displays the Specify Oracle Inventory screen.
On the Specify Inventory Directory screen, enter values for the Oracle Inventory Directory and the Operating System Group Name. For example:

Specify the Inventory Directory: /u01/app/oraInventory

Operating System Group Name: oinstall

A dialog box appears with the following message:

"Certain actions need to be performed with root privileges before the install can continue. Please execute the script /u01/app/oraInventory/createCentralInventory.sh now from another window and then press "Ok" to continue the install. If you do not have the root privileges and wish to continue the install select the "Continue installation with local inventory" option"

Log in as root and run the "/u01/app/oraInventory/createCentralInventory.sh"

This sets the required permissions for the Oracle Inventory Directory and then brings up the Welcome screen.
Note:
The Oracle Inventory screen is not shown if an Oracle product was previously installed on the host. If the Oracle Inventory screen is not displayed for this installation, make sure to check and see:
1. If the /etc/oraInst.loc file exists
2. If the file exists, the Inventory directory listed is valid
3. The user performing the installation has write permissions for the Inventory directory
On the Welcome screen, click Next.
On the Select Installation Type screen, select Install and Configure and then click Next.
On the Prerequisite Checks screen, the installer completes the prerequisites check. If any fail, please fix them and restart your installation.

Click Next.
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
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.
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.
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.
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.
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.
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.
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.
On the Configuration screen, multiple configuration assistants are launched in succession; this process can be lengthy. When it completes, click Next.
On the Installation Complete screen, click Finish to confirm your choice to exit.

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

On OVDHOST1, go the following directory:

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

For example:

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

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.
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.
Start the Administration Server on OVDHOST1 using the startWebLogic.sh script located under the MW_HOME/user_projects/domains/domainName/bin directory.
Validate that the changes were successful by opening a web browser and accessing the following pages:
- WebLogic Server Administration Console at:
```
http://oidhost1.mycompany.com:7001/console
```
- Oracle Enterprise Manager Fusion Middleware Control at:
```
http://oidhost1.mycompany.com:7001/em
```
Log into these consoles using the weblogic user credentials.

7.4.3.2.4 Installing an Additional Oracle Virtual Directory

The schema database must be running before you perform this task. Follow these steps to install the Oracle Virtual Directory instance on OVDHOST2:

Ensure that the system, patch, kernel and other requirements are met. These are listed in Oracle Fusion Middleware Installation Guide for Oracle Identity Management in the Oracle Fusion Middleware documentation library for the platform and version you are using.
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"
```
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.
Copy the staticports.ini file from the Disk1/stage/Response directory to a temporary directory.
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 port for Oracle Virtual Directory
Oracle Virtual Directory port = 6501
# The SSL port for Oracle Virtual Directory
Oracle Virtual Directory (SSL) port = 7501
```
Start the Oracle Identity Management 11g Installer as follows:

On UNIX, issue this command: runInstaller

On Windows, double-click setup.exe

The runInstaller and setup.exe files are in the ../install/platform directory, where platform is a platform such as Linux or Win32.

This displays the Specify Oracle Inventory screen.
On the Specify Inventory Directory screen, enter values for the Oracle Inventory Directory and the Operating System Group Name. For example:

Specify the Inventory Directory: /u01/app/oraInventory

Operating System Group Name: oinstall

A dialog box appears with the following message:

"Certain actions need to be performed with root privileges before the install can continue. Please execute the script /u01/app/oraInventory/createCentralInventory.sh now from another window and then press "Ok" to continue the install. If you do not have the root privileges and wish to continue the install select the "Continue installation with local inventory" option"

Log in as root and run the "/u01/app/oraInventory/createCentralInventory.sh"

This sets the required permissions for the Oracle Inventory Directory and then brings up the Welcome screen.
Note:
The Oracle Inventory screen is not shown if an Oracle product was previously installed on the host. If the Oracle Inventory screen is not displayed for this installation, make sure to check and see:
1. If the /etc/oraInst.loc file exists
2. If the file exists, the Inventory directory listed is valid
3. The user performing the installation has write permissions for the Inventory directory
On the Welcome screen, click Next.
On the Select Installation Type screen, select Install and Configure and then click Next.
On the Prerequisite Checks screen, the installer completes the prerequisites check. If any fail, please fix them and restart your installation.

Click Next.
On the Select Domain screen, select Extend Existing Domain and specify the following values:
- HostName: ovdhost1.mycompany.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>
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 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.
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.
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.
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.
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.
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.
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.
On the Configuration screen, multiple configuration assistants are launched in succession; this process can be lengthy. When it completes, click Next.
On the Installation Complete screen, click Finish to confirm your choice to exit.

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

7.4.3.3.1 Configuring Oracle Virtual Directory with a RAC Database

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

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

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

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

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

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

Configure your environment by following the steps in the "Configuring Your Environment" section of Oracle Fusion Middleware User Reference for Oracle Identity Management. That section has a list of the environment variables you must set before using the ldapbind command.
On OVDHOST1, use the opmnctl command to stop the Oracle Virtual Directory instance:
```
ORACLE_INSTANCE/bin/opmnctl stopproc ias-component=ovd1
```
On OVDHOST2, check the status of Oracle Virtual Directory by binding to the load balancing virtual address using ldapbind:

Non-SSL:
```
ldapbind -h ovd.mycompany.com -p 6501 -D "cn=orcladmin" -q
```
Note:
The -q option above prompts the user for a password. LDAP tools have been modified to disable the options -w password and -P password when the environment variable LDAP_PASSWORD_PROMPTONLY is set to TRUE or 1. Use this feature whenever possible.
A successful bind shows that the load balancer is routing all traffic to OVDHOST2.

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

On OVDHOST2, use the opmnctl command to stop the Oracle Virtual Directory instance:
```
ORACLE_INSTANCE/bin/opmnctl stopproc ias-component=ovd1
```
On OVDHOST1, check the status of Oracle Virtual Directory by binding to the load balancing virtual address using ldapbind:

Non-SSL:
```
ldapbind -h ovd.mycompany.com -p 6501 -D "cn=orcladmin" -q
```

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 User Reference for Oracle Identity Management.

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

Create an Oracle Wallet by executing the following command:

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

Export the Oracle Virtual Directory server certificate by executing 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

Add the Oracle Virtual Directory server certificate to the Oracle Wallet by executing the following command:

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

Follow the instructions shown in Section 7.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 executing 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
```
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.

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

7.4.5.1 Performing an Oracle Virtual Directory Failover

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

Use the opmnctl command to stop the Oracle Virtual Directory instance:
```
ORACLE_INSTANCE/bin/opmnctl stopproc ias-component=ovd1
```

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

Check the status of Oracle Virtual Directory:

ORACLE_INSTANCE/bin/opmnctl status ias-component=ovd1

7.4.5.2 Performing a RAC Failover

Follow these steps to perform a RAC failover:

Use the srvctl command to stop a database instance:

srvctl stop instance -d db_unique_name -i inst_name_list

Use the srvctl command to check the status of the database:
```
srvctl status database -d db_unique_name -v
```

Check the status of Oracle Virtual Directory:

ORACLE_INSTANCE/bin/opmnctl status ias-component=ovd1

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 RAC failover fails. However, subsequent search requests succeed without any issues.

7.4.6 Troubleshooting Oracle Virtual Directory High Availability

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

ORACLE_INSTANCE/diagnostics/log/OVD/<OVDComponentName>

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

diagnostic.log: This file captures diagnostic messages.
http-errors.log: This file captures HTTP errors.
access.log: This file captures information about processes and clients that access the Oracle Virtual Directory instance.

7.4.6.1 Troubleshooting LDAP Adapter Creation

When creating an LDAP adapter, you specify the host name 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 Loadbalancer 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 loadbalancer host and port details, specify the host and port details of LDAP servers front-ended by the Loadbalancer, 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.

7.5 Oracle Directory Integration Platform High Availability

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

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

7.5.1 Oracle Directory Integration Platform Component Architecture

Oracle Directory Integration Platform is a J2EE application that enables you to integrate your applications and directories, including third-party LDAP directories, with Oracle Internet Directory.

Oracle Directory Integration Platform includes services and interfaces that allow you to deploy synchronization solutions with other enterprise repositories. It can also be used to provide Oracle Internet Directory interoperability with third party metadirectory solutions.

Oracle Directory Integration Platform provides two distinct services depending on the type of integration needed:

Synchronization through the Oracle Directory Integration Platform Synchronization Service, which keeps connected directories consistent with the central Oracle Internet Directory.
Notification through Oracle Directory Integration Platform Provisioning Service, which sends notifications to target applications periodically to reflect changes made to a user's status or information.
Note:
Throughout the rest of this chapter, these terms will be used:
- "Synchronization Service" for Oracle Directory Integration Platform Synchronization Service
- "Provisioning Service" for Oracle Directory Integration Platform Provisioning Service

Figure 7-6 shows the Oracle Directory Integration Platform architecture.

Figure 7-6 Oracle Directory Integration Platform Architecture

Description of "Figure 7-6 Oracle Directory Integration Platform Architecture"

Figure 7-6 shows the various components of Oracle Directory Integration Platform. Oracle Internet Directory is synchronized with connected directories using Oracle Directory Integration Platform's Synchronization Enterprise JavaBeans (EJB) and the Quartz Scheduler.

Similarly, changes in Oracle Internet Directory are sent to various applications using Oracle Directory Integration Platform's Provisioning Enterprise JavaBeans (EJB) and the Quartz Scheduler.

7.5.1.1 Oracle Directory Integration Platform Component Characteristics

Oracle Directory Integration Platform is a J2EE application that enables you to integrate your applications and directories, including third-party LDAP directories, with Oracle Internet Directory.

Oracle Directory Integration Server provides synchronization services through the Synchronization Service and integration services through the Provisioning Service, as described below:

The Synchronization Service provides:
- Scheduling: Processing a synchronization profile based on a predefined schedule
- Mapping: Executing rules for converting data between connected directories and Oracle Internet Directory
- Data propagation: Exchanging data with connected directories by using a connector
- Error handling
The Provisioning Service provides:
- Data propagation: Exchanging data with connected directories by using a connector
- Event notification: Notifying an application of a relevant change to the user or group data stored in Oracle Internet Directory
- Error handling

Oracle Directory Integration Platform is deployed on Oracle WebLogic Server. By default, Oracle Directory Integration Platform is installed as part of the Oracle Identity Management software stack; however, depending on your architectural requirements, it can also be installed as a standalone application.

7.5.1.1.1 Runtime Processes

The Oracle Directory Integration Server provides:

The Synchronization Service using the Synchronization Enterprise JavaBeans (EJB) and the Quartz Scheduler. The Synchronization EJB is stateless in nature.

The Quartz scheduler invokes the Synchronization EJBs that synchronize the appropriate change to all the connected directories.

The Synchronization Service supplies these changes using the interface and format required by the connected directory. Synchronization through the Oracle Directory Integration Platform connectors ensures that Oracle Internet Directory remains up-to-date with all the information that Oracle Internet Directory clients need.
The Provisioning Service uses the Provisioning Enterprise JavaBeans (EJB) and the Quartz Scheduler. The Provisioning EJB is stateless in nature.

The Quartz scheduler invokes the Provisioning EJBs that in turn notify each of the provisioned application of the changes.
UpdateJob EJB periodically polls the Oracle Internet Directory changelog for changes in the Synchronization or Provisioning Profiles. When a profile change is detected, the Quartz scheduler jobs are updated accordingly.

7.5.1.1.2 Process Lifecycle

Oracle Directory Integration Platform is deployed to an Oracle WebLogic Server as an externally managed application. By default, the Oracle Directory Integration Platform application leverages the underlying WebLogic Server infrastructure for startup, shutdown, monitoring and other lifecycle events. WebLogic Node Manager can be configured to monitor the server process and restart it in case of failure.

Oracle Directory Integration Platform is initialized when the Managed Server it is deployed on starts up. After the Oracle Directory Integration Platform application starts up, the initialization code creates an initial set of jobs for the existing directory integration profiles and then invokes the UpdateJobBean EJB.

UpdateJobBean updates the jobs submitted to the Quartz Scheduler.

Depending upon the job, the Quartz scheduler invokes either the Provisioning EJB or the Synchronization EJB. If the Provisioning EJB is invoked, it, in turn, notifies each of the provisioned application of the changes to the Oracle Internet Directory. If the Synchronization EJB is invoked, it, in turn, synchronizes the appropriate change to all the connected directories.

Star ting and Stopping

The Oracle Directory Integration Platform lifecycle events can be managed using one or more of the command line tools and consoles listed below:

Oracle WebLogic Scripting Tool (WLST)
Oracle Enterprise Manager Fusion Middleware Control
Oracle WebLogic Server Administration Console
Oracle WebLogic Node Manager

7.5.1.1.3 Request Flow

Oracle Directory Integration Platform does not service any external requests. Its main functionality is to support synchronization or provisioning based on the profiles created.

This section describes the information flow during synchronization and provisioning.

Oracle Directory Integration Platform Synchronization Service Flow

Oracle Directory Integration Platform relies on the directory synchronization profiles to synchronize changes between Oracle Internet Directory and the connected directories.

Depending on where the changes are made, synchronization can occur:

From a connected directory to Oracle Internet Directory
From Oracle Internet Directory to a connected directory
In both directions

Synchronizing from Oracle Internet Directory to a Connected Directory

Oracle Internet Directory maintains a change log in which it stores incremental changes made to directory objects. It stores these changes sequentially based on the change log number.

Synchronization from Oracle Internet Directory to a connected directory makes use of this change log. Consequently, when running the Oracle Directory Integration Platform, you must start Oracle Internet Directory with the default setting in which change logging is enabled.

Each time the Oracle Directory Integration Platform Synchronization Service processes a synchronization profile, it:

Retrieves the latest change log number up to which all changes have been applied.
Checks each change log entry more recent than that number.
Selects changes to be synchronized with the connected directory by using the filtering rules in the profile.
Applies the mapping rules to the entry and makes the corresponding changes in the connected directory.

The appropriate entries or attributes are then updated in that connected directory. If the connected directory does not use DB, LDAP, tagged, or LDIF formats directly, then the agent identified in its profile is invoked. The number of the last change successfully used is then stored in the profile.

Periodically, Oracle Internet Directory purges the change log after all profiles have used what they need, and identifies where subsequent synchronization should begin.

Synchronizing from a Connected Directory to Oracle Internet Directory

When a connected directory uses DB, LDAP, tagged, or LDIF formats directly, changes to its entries or attributes can be automatically synchronized by the Oracle Directory Integration Platform Synchronization Service. Otherwise, the connector has an agent in its synchronization profile, which writes the changes to a file in the LDIF or tagged format. The Oracle Directory Integration Platform Synchronization Service then uses this file of connected directory data to update Oracle Internet Directory.

Provisioning Flow

Provisioning refers to the process of providing users, groups, and other objects with access to applications and other resources that are available within an environment. A provisioning-integrated application refers to an application that has registered for provisioning events and registered a provisioning-integration profile in Oracle Internet Directory.

An application can be provisioned with Oracle Directory Integration Platform Provisioning in one of the methods below:

Synchronous provisioning
Asynchronous provisioning
Provisioning data flow

Each of these provisioning methods is described in its own section below.

Synchronous Provisioning

Applications that maintain user information in Oracle Internet Directory and use the Data Access Java plug-in to create, modify, and delete user entries whenever the change occurs in Oracle Internet Directory are said to be provisioned synchronously, since the Data Access Java plug-in can be invoked directly from Oracle Identity Management, including the Provisioning Console and command-line LDAP tools.

Synchronous provisioning with the Oracle Directory Integration Platform Provisioning Service can be invoked from Oracle Identity Management Tools (such as the Provisioning Console in the Oracle Fusion Middleware Control and bulkprov), synchronization with third-party directories, or command-line LDAP tools.

Synchronous provisioning with the Oracle Directory Integration Platform Provisioning Service from Oracle Identity Management Tools such as through the Provisioning Console screen in the Oracle Fusion Middleware Control, bulk provisioning with the provProfileBulkProv command, and from third-party directories follows this process:

A new user entry is created in Oracle Internet Directory.
The Oracle Identity Management component that created the new user entry invokes the Data Access Java plug-in.
The Data Access Java plug-in provisions the new user account in the application.

Synchronous provisioning from command line LDAP tools follows this process:

A command-line LDAP tool creates a new user entry in Oracle Internet Directory.
At the next scheduled synchronization interval, the Oracle Directory Integration Platform identifies new user entries in Oracle Internet Directory that require provisioning.
The Oracle Directory Integration Platform invokes the Data Access Java plug-in.
The Data Access Java plug-in provisions the new user accounts in the application.

Asynchronous Provisioning

In asynchronous provisioning, the provisioning is handled by a PL/SQL plug-in and not by any component of Oracle Identity Management

The Oracle Directory Integration Platform propagates PL/SQL events to a provisioning-integrated application, which then executes a PL/SQL plug-in to process the events. Execution of a PL/SQL plug-in occurs within the application repository and not within the address space of any Oracle Identity Management component. Because provisioning is handled by a PL/SQL plug-in and not by any component of Oracle Identity Management, provisioning-integrated applications that implement a PL/SQL plug-in are provisioned asynchronously.

Asynchronous provisioning with the Oracle Directory Integration Platform Provisioning Service can be invoked from Oracle Identity Management Tools (such as Provisioning Console and bulkprov), synchronization with third-party directories, or command-line LDAP tools.

Asynchronous provisioning from Oracle Identity Management Tools such as the Provisioning Console, bulk provisioning with the provProfileBulkProv command, and third-party directories follows this process:

A new user entry and an associated entry containing application-specific user preferences are created in Oracle Internet Directory.
At the next scheduled synchronization interval, the Oracle Directory Integration Platform identifies new user entries in Oracle Internet Directory that require provisioning.
Provisioning events are sent from the Oracle Directory Integration Platform to the PL/SQL plug-in.

Asynchronous provisioning using command line LDAP tools follows this process:

A new user entry is created in Oracle Internet Directory using a command-line LDAP tool.
At the next scheduled synchronization interval, the Oracle Directory Integration Platform identifies new user entries in Oracle Internet Directory that require provisioning, and creates an associated entry containing application-specific user preferences.
Provisioning events are sent from the Oracle Directory Integration Platform to the PL/SQL plug-in.

Provisioning Data Flow

Regardless of whether it is provisioned synchronously or asynchronously, an application can invoke the Pre-Data Entry and Post-Data Entry plug-ins to enhance provisioning intelligence and implement business policies. Both plug-ins are invoked by Oracle Identity Management components such as the Oracle Internet Directory Provisioning Console and bulk provisioning with the provProfileBulkProv command.

The Pre-Data Entry plug-in populates fields according to provisioning policies. The primary purpose of this plug-in is to determine whether a user should be provisioned in an application. For example, if an organization has a a policy where only managers are provisioned for a financial application, the Pre-Data Entry plug-in can be used to identify which user entries to provision. Common user attributes are already populated when this plug-in is invoked, so it should have adequate information to make provisioning decisions.

The Post-Data Entry plug-in primarily validates data entered by users for common attributes and application-specific attributes. The validation for the plug-in must be successful for provisioning to continue.

The provisioning data flow follow this process:

Base user information is created.
The Pre-Data Entry plug-in is invoked, which populates fields according to policies.
The Post-Data Entry plug-in is invoked, which validates data entered by the user.
Depending on the provisioning approach, either asynchronous or synchronous provisioning procedures are invoked.

If provisioning is performed with the Provisioning Console, then after the Pre-Data Entry Plug-in is invoked, but before the Post-Data Entry plug-in is invoked, an administrator can modify the application attributes.

7.5.1.1.4 Configuration Artifacts

Oracle Directory Integration Platform-related configuration details are maintained in the dip-config.xml file. This configuration file is packaged as part of the Oracle Directory Integration Platform application. The default location for the dip-config.xml file is:

MW_HOME/user_projects/domains/domainName/config/
fmw_config/serverName/applications/DIP_11.1.1.2.0/configuration

Where domainName is the name of your domain serverName is the name of your managed server.

The parameters are managed using Config MBeans. Table 7-6 shows the configuration parameters required in dip-config.xml to start the Oracle Directory Integration Platform:

Table 7-6 Configuration Parameters Required to Start Directory Integration Platform

Parameter	Description
OID Host	Host name of the Oracle Internet Directory to which Oracle Directory Integration Platform needs to connect.
OID Port	The Oracle Internet Directory port
SSL Mode	The SSL mode used to connect to Oracle Internet Directory. Valid values are: 0: non-SSL 1: SSL with no authentication (handshake only). This is the default mode 2: SSL with server-only authentication enabled. Authentication is based on the Trust Point Certificate.
JKS Location	File system location to store the Java Keystore (JKS)
Quartz Threads	Maximum number of threads that can be used by Quartz for scheduling the processes.

Once the Oracle Directory Integration Platform server is up and running, it reads further details from Oracle Internet Directory for handling its synchronization and provisioning functions.

For information on creating synchronization profiles and provisioning profiles, see:

7.5.1.1.5 External Dependencies

Oracle Directory Integration Platform uses an Oracle Internet Directory to store its metadata. The Quartz Scheduler uses the ODSSM schema to store its scheduling information in the database. The same database is used by Oracle Internet Directory and Oracle Directory Integration Platform. The ODSSM schema required for Oracle Directory Integration Platform is created as part of Oracle Internet Directory schema creation.

Oracle Directory Integration Platform is also dependent on the Oracle Credential Store Framework (CSF), a secure framework provided by Oracle and the Java Keystore (JKS) to store wallets and credentials used to connect to Oracle Internet Directory and third party LDAP stores over SSL.

Oracle Directory Integration Platform is also dependent on the Oracle Fusion Middleware Common Audit Framework, which is installed by default.

7.5.1.1.6 Oracle Directory Integration Platform Log File

Oracle Directory Integration Platform is a J2EE application deployed on top of Oracle WebLogic Server. All log messages are logged in the server log file of the Oracle WebLogic Server that the application is deployed on. The default location of the server log is:

WEBLOGIC_SERVER_HOME/user_projects/domains/domainName/servers/serverName/logs/
serverName-diagnostic.log

7.5.2 Oracle Directory Integration Platform High Availability Concepts

This section provides conceptual information about using Oracle Directory Integration Platform in a high availability configuration.

In the Oracle Directory Integration Platform high availability configuration described in this section, Oracle Directory Integration Platform and Oracle Directory Services Manager are installed and configured on two hosts in a two-node high availability active-active configuration.

7.5.2.1 Oracle Directory Integration Platform High Availability Architecture

Figure 7-7 shows the Oracle Directory Integration Platform and Oracle Directory Services Manager high availability architecture in an active-active configuration.

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

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

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

On IDMHOST1, the following installations have been performed:

An Oracle Directory Integration Platform instance and Oracle Directory Services Manager instance have been installed on the WLS_ODS1 Managed Server. The RAC database has been configured in a JDBC multi data source to protect the instances from RAC node failure.
A WebLogic Administration Server has been installed. Under normal operations, this is the active Administration Server.

On IDMHOST2, the following installations have been performed:

An Oracle Directory Integration Platform instance and Oracle Directory Services Manager instance have been installed in the WLS_ODS2 Managed Server. The RAC database has been configured in a JDBC multi data source to protect the instances from 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.

7.5.2.1.1 Starti ng and Stopping the Cluster

In a high availability architecture, Oracle Directory Integration Platform and Oracle Directory Services Manager are deployed on an Oracle WebLogic Cluster that has at least two servers as a part of the cluster.

By default, the WebLogic Server starts, stops and monitors the applications. By default, both the Oracle Directory Integration Platform and Oracle Directory Services Manager applications leverage the high availability features of the underlying WebLogic Clusters. In case of hardware or other failures, session state is available to other cluster nodes that can resume the work of the failed node.

In a high availability environment, WebLogic Node Manager is configured to monitor the WebLogic servers. In case of failure, Node Manager restarts the WebLogic Server. If Node Manager cannot restart the server, then the front-ending load balancing router detects failure of a WebLogic instance in the Cluster and routes traffic to surviving instances.

7.5.2.1.2 Cluster-Wide Configuration Changes

When Oracle Internet Directory is deployed in an active-active high availability configuration, all the Oracle Internet Directory instances belonging to the cluster share the same database. Any changes made to Oracle Directory Integration Platform on one Oracle Internet Directory node would automatically be propagated to all the Oracle Internet Directory instances in the cluster.

The following subsections describe configuration changes made to the Oracle Directory Integration Platform application in an Oracle Internet Directory multimaster replication deployment. In a multimaster replication deployment, configuration changes need to be applied to all the nodes in the cluster manually, as described below.

Directory Integration Profiles

Changes made to directory integration profiles on one Oracle Internet Directory node are not automatically replicated to other Oracle Internet Directory nodes in a default multimaster Oracle Internet Directory replication environment. They need to be manually copied over from the primary node to the secondary nodes on a periodic basis. This allows a directory synchronization profile to execute on a secondary node in the event of a problem on the primary node.

One of the parameters used by Oracle Directory Integration Platform is orcllastappliedchangenumber. The value assigned to the lastchangenumber attribute in a directory synchronization profile depends on the directory server on which Oracle Directory Integration Platform is running. In an active-active Oracle Directory Integration Platform configuration, you must manually update the lastchangenumber attribute in all instances.

The next section details the steps to copy the synchronization profiles and the provisioning profiles from the primary Oracle Internet Directory to the secondary Oracle Internet Directory in a multimaster replication deployment.

Directory Synchronization Profiles

After copying an export profile to a target node the lastchangenumber attribute must be updated with the value from the target node. Follow the steps below to update the value:

Disable the synchronization profile.
Get the value of the lastchangenumber attribute on the target node using the ldapsearch command.
Use ldapsearch to get the LDIF dump of the profile entry.
Use ldapadd to add the profile to the other Oracle Internet Directory instance.
Use the updatechgnum operation of the manageSyncProfiles command to update the lastchangenumber attribute in the export profile you copied to the target node with the value you obtained in Step 2.
Enable the synchronization profile.

Directory Provisioning Profiles

In a default multimaster Oracle Internet Directory replication environment, the Oracle Directory Integration Platform is installed in the same location as the primary Oracle Internet Directory. The information and steps in this section are applicable only when multimaster replication is set up.

If the primary node fails, event propagation stops for all profiles located on the node. Although the events are queued and not lost while the primary node is stopped, the events will not be propagated to any applications that expect them. To ensure that events continue to be propagated even when the primary node is down for the Version 1.0 and 2.0 profiles, the directory provisioning profiles must be copied to other secondary nodes.

However, directory provisioning profiles should only be copied from the primary node to any secondary nodes immediately after an application is installed and before any user changes are made in Oracle Internet Directory.

To synchronize the directory provisioning profiles between a primary node and any secondary nodes, you need to do the following:

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
```
Copy the LDIF dump to the secondary node.
Use the ldapadd command to add the profiles on the secondary node.

7.5.2.2 Protection from Failures and Expected Behavior

This section discusses protection from different types of failure in an Oracle Directory Integration Platform active-active cluster.

7.5.2.2.1 Process Failure

In a high availability environment, the Oracle Directory Integration Platform application is deployed on an Oracle WebLogic Server cluster comprised of at least two WebLogic instances.

By default, the Oracle Directory Integration Platform application leverages the high availability features of the underlying WebLogic Clusters. When Oracle Directory Integration Platform is deployed, the Quartz scheduler is started with a clustering option. When started with the clustering option, depending on the load on the node, the scheduler runs the job on any of the available nodes in the cluster. In case of hardware or other failures on one or more nodes, the scheduler runs the jobs on the available nodes.

In addition, in a high availability environment, WebLogic Node Manager is configured to monitor the WebLogic servers. In case of failure, Node Manager restarts the WebLogic Server.

Within the Oracle Directory Integration Platform application, the Quartz Scheduler invokes the Provisioning or Synchronization EJBs that do the actual work. As soon as the Quartz scheduler invokes an EJB, it tags that EJB as executing the job. In case the EJB fails, the Quartz scheduler marks the job as failed and reschedules it to be executed later by another EJB.

7.5.2.2.2 Expected Client Application Behavior When Failure Occurs

Oracle Directory Integration Platform failover is not transparent to end users.

Configuration changes made on a Oracle Directory Integration Platform instance deployed in a high availability topology are not propagated automatically to all the Oracle Directory Integration Platform instances in the topology.

It is recommended that you use the manageDIPServerConfig tool to make the same configuration changes on all Oracle Directory Integration Platform instances in the topology. This ensures that the configuration across all the Oracle Directory Integration Platform instances in the topology is uniform.

See Oracle Fusion Middleware Integration Guide for Oracle Identity Management for more information about the manageDIPServerConfig tool.

7.5.2.2.3 External Dependency Failure

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

7.5.2.3 Oracle Directory Integration Platform Prerequisites

This section describes prerequisites for setting up Oracle Directory Integration Platform in the high availability architecture.

Note:

Oracle Directory Integration Platform uses Quartz to maintain its jobs and schedules in the database. For the Quartz jobs to be run on multiple Oracle Directory Integration Platform nodes in a cluster, it is required that the system clocks on the cluster nodes be synchronized.

Oracle Internet Directory should be installed and configured by following the instructions in these sections:

Section 7.3.2.3, "Oracle Internet Directory Prerequisites"
Section 7.3.3, "Oracle Internet Directory High Availability Configuration Steps"

7.5.3 Oracle Directory I ntegration Platform and Oracle Directory Services Manager High Availability Configuration Steps

In a high availability environment, it is recommended that Oracle WebLogic Server utilities be used for clustering, load balancing, and failover of Oracle Directory Integration Platform instances and Oracle Directory Services Manager.

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

Installing the WebLogic Administration Server on IDMHOST1 and IDMHOST2
Installing and Configuring Oracle Directory Integration Platform and Oracle Directory Services Manager on IDMHOST1
"Creating boot.properties for the Administration Server on IDMHOST1"
Installing and Configuring Oracle Directory Integration Platform and Oracle Directory Services Manager on IDMHOST2
Post-Installation Steps for Oracle Directory Integration Platform and Oracle Directory Services Manager
Installing Oracle HTTP Server on WEBHOST1 and WEBHOST2

It is not required to install Oracle Directory Integration Platform and Oracle Directory Services Manager in the same installation session, on the same Managed Server, or on the same host. The installation and configuration steps in this section are one example of installing Oracle Directory Integration Platform and Oracle Directory Services Manager in a two-node active-active cluster.

7.5.3.1 Installing the W ebLogic Administration Server on IDMHOST1 and IDMHOST2

On IDMHOST1 and IDMHOST2, start the Oracle WebLogic Server installation by running the installer executable file.

Start the Oracle WebLogic Server installer as follows:

On UNIX (Linux in the following example):
```
./wls1032_linux32.bin
```
On Windows:
```
wls1032_win32.exe
```

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

On the Welcome screen, click Next.
On the Choose Middleware Home Directory screen, choose a directory on your computer into which the Oracle WebLogic software is to be installed.

For the Middleware Home Directory, specify this value:
```
/u01/app/oracle/product/fmw
```
Click Next.
On the Register for Security Updates screen, enter your "My Oracle Support" User Name and Password.
On the Choose Install Type screen, the installation program displays a window in which you are prompted to indicate whether you wish to perform a complete or a custom installation.

Choose Typical or Custom (Typical is chosen in this example)

Click Next.
On the Choose Product Installation Directories screen, specify the following value for this field:
- WebLogic Server:
```
/u01/app/oracle/product/fmw/wlserver_10.3
```
Click Next.
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.
On the Installation Complete screen, deselect the Run Quickstart checkbox.

Click Done.

7.5.3.2 Installing and Confi guring Oracle Directory Integration Platform and Oracle Directory Services Manager on IDMHOST1

Follow these steps to install and configure Oracle Directory Integration Platform and Oracle Directory Services Manager on IDMHOST1:

Ensure that the system, patch, kernel and other requirements are met. These are listed in Oracle Fusion Middleware Installation Guide for Oracle Identity Management in the Oracle Fusion Middleware documentation library for the platform and version you are using.
Ensure that port 7006 is 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 ":7006"
```
On Windows:
```
netstat -an | findstr "LISTEN" | findstr ":7006"
```
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 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.
Copy the staticports.ini file from the Disk1/stage/Response directory to a temporary directory.
Edit the staticports.ini file that you copied to the temporary directory to assign the following custom ports (uncomment the line where you specify the port numbers for Oracle Directory Services Manager):
```
# The port for ODSM server
ODS Server port = 7006
```
Start the Oracle Identity Management 11g Installer as follows:

On UNIX, issue this command: runInstaller

On Windows, double-click setup.exe

The runInstaller and setup.exe files are in the ../install/platform directory, where platform is a platform such as Linux or Win32.

This displays the Specify Oracle Inventory screen.
On the Specify Inventory Directory screen, enter values for the Oracle Inventory Directory and the Operating System Group Name. For example:

Specify the Inventory Directory: /u01/app/oraInventory

Operating System Group Name: oinstall

A dialog box appears with the following message:

"Certain actions need to be performed with root privileges before the install can continue. Please execute the script /u01/app/oraInventory/createCentralInventory.sh now from another window and then press "Ok" to continue the install. If you do not have the root privileges and wish to continue the install select the "Continue installation with local inventory" option"

Log in as root and run the "/u01/app/oraInventory/createCentralInventory.sh"

This sets the required permissions for the Oracle Inventory Directory and then brings up the Welcome screen.
Note:
The Oracle Inventory screen is not shown if an Oracle product was previously installed on the host. If the Oracle Inventory screen is not displayed for this installation, make sure to check and see:
1. If the /etc/oraInst.loc file exists
2. If the file exists, the Inventory directory listed is valid
3. The user performing the installation has write permissions for the Inventory directory
On the Welcome screen, click Next.
On the Select Installation Type screen, select Install and Configure and then click Next.
On the Prerequisite Checks screen, the installer completes the prerequisite check. If any fail, fix them and restart your installation.

Click Next.
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.
On the Specify Installation Location screen, specify the following values:
- Oracle Middleware Home Location:
```
/u01/app/oracle/product/fmw
```
- Oracle Home Location:
```
ods
```
- WebLogic Server Directory:
```
/u01/app/oracle/product/fmw/wlserver_10.3
```
- Oracle Instance Location:
```
/u01/app/oracle/admin/ods_instance1
```
- Oracle Instance Name:
```
ods_instance1
```
Click Next.
On the Specify Oracle Configuration Manager Details screen, specify these values:
- Email Address: Provide the email address for your My Oracle Support account.
- Oracle Support Password: Provide the password for your My Oracle Support account.
- Check the checkbox next to the I wish to receive security updates via My Oracle Support field.
Click Next.
On the Configure Components screen, select Oracle Directory Integration Platform, Management Components - Oracle Directory Services Manager. Deselect all the other components. Ignore the warning that says Oracle Internet Directory needs to be configured as a prerequisite.

Select the Clustered check box.

Click Next.

Note:
The default Oracle WebLogic Server clustering mode set by the installer is unicast (not multicast).
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.
On the Specify OID Details screen, specify the following:
- Hostname: oid.mycompany.com
- Port: 636
- Username: cn=orcladmin
- Password: ******
Click Next.
On the Specify Schema Database screen, select Use Existing Schema and specify the following values:
- Connect String:
```
infradbhost1-vip.mycompany.com:1521:idmdb1^infradbhost2-vip.mycompany.com:1521:idmdb2@idmedg.mycompany.com
```
  Note:
  The 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 RAC instances to be up. If one 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 RAC instance, and the service name provided must be configured for all the specified RAC instances.
  
  Any incorrect information entered in the RAC database connect string has to be corrected manually after the installation.
- User Name: ODSSM
- Password: ******
Click Next.
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.
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.
On the Configuration screen, multiple configuration assistants are launched in succession; this process can be lengthy. When it completes, click Next.
On the Installation Complete screen, click Finish to confirm your choice to exit.

7.5.3.3 Creating boot.properties for the Administration Server on IDMHOST1

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.

Follow these steps to create the boot.properties file:

On IDMHOST1, go the following directory:

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

For example:

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

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.
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.
Start the Administration Server on IDMHOST1 using the startWebLogic.sh script located under the MW_HOME/user_projects/domains/domainName/bin directory.
Validate that the changes were successful by opening a web browser and accessing the following pages:
- WebLogic Server Administration Console at:
```
http://oidhost1.mycompany.com:7001/console
```
- Oracle Enterprise Manager Fusion Middleware Control at:
```
http://oidhost1.mycompany.com:7001/em
```
Log into these consoles using the weblogic user credentials.

7.5.3.4 Installing and Confi guring Oracle Directory Integration Platform and Oracle Directory Services Manager on IDMHOST2

Follow these steps to install only the Oracle Identity Management software on IDMHOST2:

Ensure that the system, patch, kernel and other requirements are met. These are listed in Oracle Fusion Middleware Installation Guide for Oracle Identity Management in the Oracle Fusion Middleware documentation library for the platform and version you are using.
Start the Oracle Identity Management 11g Installer as follows:

On UNIX, issue this command: runInstaller

On Windows, double-click setup.exe

The runInstaller and setup.exe files are in the ../install/platform directory, where platform is a platform such as Linux or Win32.

This displays the Specify Oracle Inventory screen.
On the Specify Inventory Directory screen, enter values for the Oracle Inventory Directory and the Operating System Group Name. For example:

Specify the Inventory Directory: /u01/app/oraInventory

Operating System Group Name: oinstall

A dialog box appears with the following message:

"Certain actions need to be performed with root privileges before the install can continue. Please execute the script /u01/app/oraInventory/createCentralInventory.sh now from another window and then press "Ok" to continue the install. If you do not have the root privileges and wish to continue the install select the "Continue installation with local inventory" option"

Log in as root and run the "/u01/app/oraInventory/createCentralInventory.sh"

This sets the required permissions for the Oracle Inventory Directory and then brings up the Welcome screen.
Note:
The Oracle Inventory screen is not shown if an Oracle product was previously installed on the host. If the Oracle Inventory screen is not displayed for this installation, make sure to check and see:
1. If the /etc/oraInst.loc file exists
2. If the file exists, the Inventory directory listed is valid
3. The user performing the installation has write permissions for the Inventory directory
On the Welcome screen, click Next.
On the Select Installation Type screen, select Install & Configure and then click Next.
On the Prerequisite Checks screen, the installer completes the prerequisite check. If any fail, please fix them and restart your installation.

Click Next.
On the Select Domain screen, select the Expand Cluster option and specify the values shown in the example below:
- HostName: idmhost1.mycompany.com
- Port: 7001
- UserName: weblogic
- User Password: <password for the weblogic user>
Click Next.

Note:
IDMHOST1 is where the Oracle WebLogic Administration Server is running.
On the Specify Installation Location screen, specify the following values:
- Oracle Middleware Home Location:
```
/u01/app/oracle/product/fmw
```
- Oracle Home Directory:
```
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.
On the Configure Components screen, de-select all products except Oracle DIP and Management Components.

Click Next.
On the Configure Ports screen, select Specify Ports Using Configuration File and enter the full pathname to the staticports.ini file that you edited in the temporary directory.

Click Next.
On the Installation Summary screen, review the choices you made. If you need to make any changes, click Back. If you made the correct selections, click Install.
On the Installation Progress screen, view the progress of the installation.
On UNIX systems, 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 b ox open, open another shell window, log in as root, and run this script file:
```
/u01/app/oracle/product/fmw/ods/oracleRoot.sh
```
On the Configuration Progress screen, view the progress of the configuration.
On the Installation Complete screen, click Finish to confirm your choice to exit.

7.5.3.5 Post-Installation Steps for Orac le Directory Integration Platform and Oracle Directory Services Manager

In the previous section, the installer created a second Managed Server, wls_ods2 on IDMHOST2. However, the Oracle Directory Integration Platform application is not deployed on IDMHOST2 and the newly created Managed Server is not automatically started. Also, the WebLogic Administration Console shows the state of the wls_ods2 Managed Server on IDMHOST2 as UNKNOWN.

Follow the post-installation steps in this section to complete the installation and configuration of the Oracle Directory Integration Platform and Oracle Directory Services Manager applications on IDMHOST2.

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

To copy the Oracle Directory Integration Platform directly application from IDMHOST1 to IDMHOST2:

Copy the following directory on IDMHOST1: MW_HOME/user_projects/domains/IDMDomain/config/fmwconfig/servers/wls_ods1/applications to the following location on IDMHOST2: MW_HOME/user_projects/domains/IDMDomain/config/fmwconfig/servers/wls_ ods2/applications.

For example, from IDMHOST1, execute the following command:

scp -rp MW_HOME/user_projects/domains/IDMDomain/config/fmwconfig/servers/wls_ods1/applicationsuser@IDMHOST2:/MW_HOME/user_projects/domains/IDMDomain/config/fmwconfig/servers/wls_ods2/applications

7.5.3.5.2 Start the Managed Server on IDMHOST2 in a Cluster

Follow these steps to start the newly-created wls_ods2 Managed Server in a cluster on IDMHOST2:

In a web browser, use this URL to access the Oracle WebLogic Server Administration Console:
```
http://idmhost1.mycompany.com:7001/console
```
Log into the console using the administrator's credentials.
In the left pane of the Oracle WebLogic Server Administration Console, expand Environment and select Clusters.

See the "Starting and Stopping Oracle Fusion Middleware" chapter of the Oracle Fusion Middleware Administrator's Guide for information on starting and stopping WebLogic Servers.
Click on the link for the cluster (cluster_ods) containing the Managed Server (wls_ods2) you want to stop.
Select Control.
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.
On the Cluster Life Cycle Assistant page, click Yes to confirm.
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.

7.5.3.6 Installing Oracle HTTP Server on WEBHOST1 and WEBHOST2

This section describes how to install Oracle HTTP Server on WEBHOST1 and WEBHOST2. Oracle HTTP Server is not required if Oracle Directory Integration Platform is the only component being installed.

Ensure that the system, patch, kernel and other requirements are met. These are listed in the Oracle Fusion Middleware Installation Guide for Web Tier in the Oracle Fusion Middleware documentation library for the platform and version you are using.
Ensure that port 7777 is not in use by any service on WEBHOST1 or WEBHOST2 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 ":7777"
```
On Windows:
```
netstat -an | findstr "LISTEN" | findstr ":7777"
```
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 port 7777 in the /etc/services file and restart the services, or restart the computer.

On Windows:

Stop the component that is using the port.
Copy the staticports.ini file from the Disk1/stage/Response directory to a temporary directory.
Edit the staticports.ini file that you copied to the temporary directory to assign the following custom ports (uncomment the line where you specify the port number for Oracle HTTP Server):
```
# The port for Oracle HTTP server
Oracle HTTP Server port = 7777
```
Start the Oracle Universal Installer for Oracle Fusion Middleware 11g Web Tier Utilities CD installation as follows:

On UNIX, issue this command: runInstaller.

On Windows, double-click setup.exe.

The runInstaller and setup.exe files are in the ../install/platform directory, where platform is a platform such as Linux or Win32.

This displays the Specify Oracle Inventory screen.
On the Specify Inventory Directory screen, enter values for the Oracle Inventory Directory and the Operating System Group Name. For example:

Specify the Inventory Directory: /u01/app/oraInventory

Operating System Group Name: oinstall

A dialog box appears with the following message:

"Certain actions need to be performed with root privileges before the install can continue. Please execute the script /u01/app/oraInventory/createCentralInventory.sh now from another window and then press "Ok" to continue the install. If you do not have the root privileges and wish to continue the install select the "Continue installation with local inventory" option"

Log in as root and run the "/u01/app/oraInventory/createCentralInventory.sh"

This sets the required permissions for the Oracle Inventory Directory and then brings up the Welcome screen.
Note:
The Oracle Inventory screen is not shown if an Oracle product was previously installed on the host. If the Oracle Inventory screen is not displayed for this installation, make sure to check and see:
1. If the /etc/oraInst.loc file exists
2. If the file exists, the Inventory directory listed is valid
3. The user performing the installation has write permissions for the Inventory directory
On the Welcome screen, click Next.
On the Select Installation Type screen, select Install and Configure, and click Next.
On the Prerequisite Checks screen, the installer completes the prerequisite check. If any fail, fix them and restart your installation.

Click Next.
On the Specify Installation Location screen:
- On WEBHOST1 and WEBHOST2, set the Location to:
```
/u01/app/oracle/admin
```
Click Next.
On the Configure Components screen:
- Select Oracle HTTP Server.
- Select Associate Selected Components with Weblogic Domain.
Click Next.
On the Specify WebLogic Domain screen:

Enter the location where you installed Oracle WebLogic Server. Note that the Administration Server must be running.
- Domain Host Name: IDMHOST1
- Domain Port No: 7001
- User Name: weblogic
- Password: ******
Click Next.
On the Specify Component Details screen:
- Enter the following values for WEBHOST1:
  - Instance Home Location: /u01/app/oracle/admin/ohs_inst1
  - Instance Name: ohs_inst1
  - OHS Component Name: ohs1
- Enter the following values for WEBHOST2:
  - Instance Home Location: /u01/app/oracle/admin/ohs_inst2
  - Instance Name: ohs_inst2
  - OHS Component Name: ohs2
Click Next.
On the Specify Webtier Port Details screen:
- Select Specify Custom Ports. If you specify a custom port, select Specify Ports using Configuration File and then use the Browse function to select the file.
- Enter the Oracle HTTP Server port, for example, 7777.
Click Next.
On the Oracle Configuration Manager screen, enter the following:
- Email Address: Provide the email address for your My Oracle Support account
- Oracle Support Password: Provide the password for your My Oracle Support account.
- I wish to receive security updates via My Oracle Support: Click this checkbox.
On the Installation Summary screen, ensure that the selections are correct. If they are not, click Back and make the necessary fixes. After ensuring that the selections are correct, click Next.
On the Installation Progress screen on UNIX systems, a dialog 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.
On the Configuration Progress screen, multiple configuration assistants are launched in succession; this process can be lengthy.
On the Configuration Completed screen, click Finish to exit.

7.5.3.6.1 Configuring Oracle HTTP Server for Oracle Directory Services Manager High Availability

Follow the instructions in this section to configure Oracle HTTP Server for Oracle Directory Services Manager high availability.

Configure Oracle HTTP Server to use the load balancing router virtual hosts.

The Oracle HTTP Server instances on WEBHOST1 and WEBHOST2 should be configured to use the virtual hosts set up in the load balancer. Refer to Section 7.2.5.5, "Configuring Virtual Server Names and Ports for the Load Balancer" for more information about the virtual hosts.

To configure the Oracle HTTP Server instances to use the load balancing router virtual hosts, edit the httpd.conf file to define the virtual host directives as follows:
```
NameVirtualHost *:7777
<VirtualHost *:7777>
   ServerName admin.mycompany.com:7777
   ServerAdmin you@your.address
   RewriteEngine On
   RewriteOptions inherit
</VirtualHost>
```
The httpd.conf file is located under the ORACLE_INSTANCE/config/OHS/componentName directory on both WEBHOST1 and WEBHOST2.
Configure Oracle HTTP Server to route to Oracle Directory Services Manager, Oracle Enterprise Manager Fusion Middleware Control, and the Oracle WebLogic Server Administration Console.

To enable the Oracle HTTP Server instances to route to the Oracle Directory Services Manager applications on IDMHOST1 and IDMHOST2, add the directives below to the mod_wl_ohs.conf file located under the ORACLE_INSTANCE/config/OHS/componentName directory on WEBHOST1 and WEBHOST2:
```
LoadModule weblogic_module "${ORACLE_HOME}/ohs/modules/mod_wl_ohs.so"

<IfModule weblogic.module>
WebLogicHost IDMHOST1.MYCOMPANY.COM
WebLogicPort PORT
</IfModule>

<Location /odsm>
SetHandler weblogic-handler
WebLogicCluster IDMHOST1.MYCOMPANY.COM:<PORT>,IDMHOST2.MYCOMPANY.COM:<PORT>
</Location>
```

Stop and start Oracle HTTP Server using the opmnctl command:

ORACLE_INSTANCE/bin/opmnctl stopall
ORACLE_INSTANCE/bin/opmnctl startall

Validate that you can access the consoles using the load balancing router virtual host:

Oracle Directory Services Manager Console:
```
http://admin.mycompany.com:7777/odsm
```
Oracle WebLogic Server Administration Console:
```
http://idmhost1.mycompany.com:7001/console
```
Oracle Enterprise Manager Fusion Middleware Control:
```
http://idmhost1.mycompany.com:7001/em
```
Note:
When Oracle Directory Integration Platform deployed in a high availability configuration is enabled for SSL with server-only Authentication (that is, SSL Mode2), it is required to use a common key store that contains the certificates of all the Oracle Internet Directory instances. You can create a common keystore by importing the certificates from all the Oracle Internet Directory instances and then copying the keystore to all nodes where Oracle Directory Integration Platform is running.
For more information about using SSL with Oracle Directory Integration Platform, refer to the Oracle Fusion Middleware Integration Guide for Oracle Identity Management.

7.5.4 Oracle Directory Integration Platform Failover and Expected Behavior

In a high availability environment, the Oracle Directory Integration Platform application is deployed on an Oracle WebLogic Server cluster comprised of at least two WebLogic instances.

By default, the Oracle Directory Integration Platform application leverages the high availability features of the underlying WebLogic Clusters. In case of hardware or other failures, session state is available to other cluster nodes that can resume the work of the failed node.

In addition, in a high availability environment, WebLogic Node Manager is configured to monitor the WebLogic servers. In case of failure, Node Manager restarts the WebLogic Server. In case of a database instance failure, the surviving RAC node takes over any remaining processes. There may be innocuous errors in the Managed Servers logs during a RAC failover, as discussed in Section 7.5.5, "Troubleshooting Oracle Directory Integration Platform High Availability."

7.5.5 Troubleshooting Oracle Directory Integration Platform High Availability

This section describes how to deal with issues involving Oracle Directory Integration Platform high availability.

7.5.5.1 Managed Server Log File Exceptions Received for Oracle Directory Integration Platform During a RAC Failover

During a RAC failover, exceptions similar to the ones below are seen in the Managed Server log files running the Oracle Directory Integration Platform application. These errors are thrown when the multi data sources configured on the WebLogic Server platform try to verify the health of the RAC database instances during failover. These are innocuous errors and can be ignored. The Oracle Directory Integration Platform application will recover and begin to operate normally after a lag of one or two minutes. During a RAC failover, there will be no Oracle Directory Integration Platform down time if one RAC instance is running at all times.

RuntimeException:
[2008-11-21T00:11:10.915-08:00] [wls_ods] [ERROR] []
[org.quartz.impl.jdbcjobstore.JobStoreTX] [tid: 25] [userId: <anonymous>]
[ecid: 0000Hqy69UiFW7V6u3FCEH199aj0000009,0] [APP: DIP] ClusterManager: Error
managing cluster: Failed to obtain DB connection from data source
'schedulerDS': java.sql.SQLException: Could not retrieve datasource via JNDI
url 'jdbc/schedulerDS' java.sql.SQLException: Cannot obtain connection:
driverURL = jdbc:weblogic:pool:schedulerDS, props =
{EmulateTwoPhaseCommit=false, connectionPoolID=schedulerDS,
jdbcTxDataSource=true, LoggingLastResource=false,
dataSourceName=schedulerDS}.[[
Nested Exception: java.lang.RuntimeException: Failed to setAutoCommit to true
for pool connection

AuthenticationException while connecting to OID:
[2008-11-21T00:12:08.812-08:00] [wls_ods] [ERROR] [DIP-10581] [oracle.dip]
[tid: 11] [userId: <anonymous>] [ecid: 0000Hqy6m54FW7V6u3FCEH199apO000000,0]
[APP: DIP] DIP was not able to get the context with the given details {0}[[
javax.naming.AuthenticationException: [LDAP: error code 49 - Invalid
Credentials]

Most of the exceptions will be related to the scheduler or LDAP, for example:

1. Could not retrieve datasource via JNDI url 'jdbc/schedulerDS' java.sql.SQLException.

2. javax.naming.AuthenticationException: [LDAP: error code 49 - Invalid Credentials]

7.5.5.2 Dealing with Error Messages Received After Starting WebLogic Node Manager

If you receive the following error message after starting WebLogic Node Manager, follow the steps that appear below after the error message:

<Dec 15, 2008 8:40:05 PM> <Warning> <Uncaught exception in server handler:
javax.net.ssl.SSLKeyException: [Security:090482]BAD_CERTIFICATE alert was
received from stbee21.us.oracle.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.us.oracle.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.

If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit.
In the left pane of the Console, expand Servers and AdminServer (admin).
Select the Configuration > SSL > Advanced Link.
Select None for Hostname Verification.
Click Save to save the setting.
To activate these changes, in the Change Center of the Administration Console, click Activate Changes.
Restart all servers.

If the Managed Server is started in Admin mode, perform these steps:

If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit.
In the left pane of the Console, expand Servers and the name of the server that is running in ADMIN mode.
Select the Control > Start/Stop tab.
Select the name of the server.
Click Resume.
Select Yes to resume servers.

7.5.5.3 If WebLogic Node Manager Fails to Start

If WebLogic Node Manager fails to start, make sure that you have copied the following domains file from IDMHOST1 to IDMHOST2:

WL_HOME/common/nodemanager/nodemanager.domains

7.5.5.4 Configuration Changes Do Not Automatically Propagate to All Oracle Directory Integration Platform Instances in a Highly Available Topology

When you change the configuration of an Oracle Directory Integration Platform instance in a high availability topology, the configuration change does not propagate automatically to all the Oracle Directory Integration Platform instances in the topology.

Instead, use the manageDIPServerConfig tool to make the same configuration change for each Oracle Directory Integration Platform instance in the topology, which will ensure the same configuration across all the Oracle Directory Integration Platform instances in the topology. See Oracle Fusion Middleware Integration Guide for Oracle Identity Management for more information about the manageDIPServerConfig tool.

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

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

7.6 Oracle Directory Services Manager High Availability

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

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

7.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 7-8 shows the Oracle Directory Services Manager architecture.

Figure 7-8 Oracle Directory Services Manager Architecture

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

Figure 7-8 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 WebServices to communicate with Oracle Virtual Directory.

7.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. By default, Oracle Directory Services Manager is deployed to the Administration Server within the WebLogic domain, but depending on the requirements in your environment, it can also be deployed to a Managed Server.

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

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

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

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

where:

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

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

Select Directory Services Manager from the Oracle Internet Directory menu in the Oracle Internet Directory target, then Data Browser, Schema, Security, or Advanced.
From the Oracle Virtual Directory menu in the Oracle Virtual Directory target, select Directory Services Manager, then Data Browser, Schema, Adapter, Extensions, or Quick configuration wizard.

A new browser window containing the Oracle Directory Services Manager Welcome screen will pop up.

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

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

The following tools can be used 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

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

7.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 Oracle Directory Integration Platform are installed and configured on two hosts in a two-node high availability active-active configuration.

7.6.2.1 Oracle Directory Services Manager High Availability Architecture

Figure 7-9 shows the Oracle Directory Integration Platform and Oracle Directory Services Manager high availability architecture in an active-active configuration.

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

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

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

On IDMHOST1, the following installations have been performed:

An Oracle Directory Integration Platform instance and Oracle Directory Services Manager instance have been installed on the WLS_ODS1 Managed Server. The RAC database has been configured in a JDBC multi data source to protect the instances from RAC node failure.
A WebLogic Administration Server has been installed. Under normal operations, this is the active Administration Server.

On IDMHOST2, the following installations have been performed:

An Oracle Directory Integration Platform instance and Oracle Directory Services Manager instance have been installed in the WLS_ODS2 Managed Server. The RAC database has been configured in a JDBC multi data source to protect the instances from 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.

7.6.2.1.1 Starti ng and Stopping the Cluster

7.6.2.2 Protection from Failures and Expected Behaviors

This section discusses protection from different types of failure in an Oracle Directory Services Manager active-active cluster.

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

In addition, in a high availability environment, WebLogic Node Manager is configured to monitor the WebLogic servers. In case of failure, Node Manager restarts the WebLogic Server. If Node Manager cannot restart the server, then mod_wl_ohs, which is configured as a part of Oracle HTTP Server, routes the request to the surviving WebLogic instance.

OPMN monitors the Oracle HTTP Server processes and restarts the process in case of failure. If OPMN is unable to restart the HTTP process, the front-ending load balancing router detects the failure of an Oracle HTTP Server instance and routes traffic to surviving instances.

Oracle Directory Services Manager maintains a session state, but in case of failure, the session state information is not carried over to the surviving node.

7.6.2.2.2 Expected Client Application Behavior When Failure Occurs

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

7.6.2.2.3 Expected Dependency Failure

Oracle Directory Services Manager requires the WebLogic Managed Server to be available during startup. If it is not available, Oracle Directory Services Manager fails to start.

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

The components listed below should be installed and configured before installing Oracle Directory Services Manager. See the sections below for the prerequisites, the installation and configuration steps of each required component:

Oracle database

Install and configure an Oracle Real Application Clusters database by following the instructions in these sections:
Oracle Repository Creation Utility

Install the Oracle Repository Creation Utility to create and load the required schemas by following the instructions in these sections:
- Section 7.2.4, "Installing the Repository Creation Utility Software"
- Section 7.2.5, "Configuring the Database for Oracle Fusion Middleware 11g Metadata"
Load balancers and virtual hosts

See Section 7.2.5.5, "Configuring Virtual Server Names and Ports for the Load Balancer" for information about configuring the load balancer and creating the required virtual server.
Oracle Internet Directory

Install and configure Oracle Internet Directory by following the instructions in these sections:
- Section 7.3.2.3, "Oracle Internet Directory Prerequisites"
- Section 7.3.3, "Oracle Internet Directory High Availability Configuration Steps"

7.6.3 Oracle Directory Services Manager High Availability Configuration Steps

See Section 7.5.3, "Oracle Directory Integration Platform and Oracle Directory Services Manager High Availability Configuration Steps" for the steps for installing and configuring the high availability active-active configuration shown in Figure 7-9.

7.6.4 Validating Oracle Directory Services Manager High Availability

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

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

Perform these steps:

Access Oracle Directory Services Manager through the Oracle HTTP Server virtual server name:
```
http://admin.mycompany.com/odsm/faces/odsm.jspx
```
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).
On the login page, enter the user name and the password you used to start the Administration Server and click Log In.
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.
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.
Access Oracle Directory Services Manager through the Oracle HTTP Server virtual server name:
```
http://admin.mycompany.com/odsm/faces/odsm.jspx
```
The Welcome to Oracle Directory Services Manager screen is displayed.

7.6.4.2 Performing a 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 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.mycompany.com

The LDAP virtual server name in this example is:

oid.mycompany.com:389

Perform these steps:

Access Oracle Directory Services Manager through the Oracle HTTP Server virtual server name:
```
http://admin.mycompany.com/odsm/faces/odsm.jspx
```
The Welcome to Oracle Directory Services Manager screen is displayed.
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.mycompany.com
  - Port: 389
  - SSL Enabled: Leave blank
  - User Name: cn=orcladmin
  - Password: ********
  - Start Page: Home (default)
Shut down the Oracle Internet Directory Schema database instance on INFRADBHOST1-VIP by running the following srvctl commands (in this example, the database name is INFRADB):
```
ORACLE_HOME/bin/srvctl stop instance -d infradb -i infradb1
ORACLE_HOME/bin/srvctl status database
```
Refresh the Oracle Directory Services Manager screen or navigate to one of the tabs (Home, Data Browser, Schema, Security, Advanced). You should still be able to access the Oracle Internet Directory information.
Restart the Oracle Internet Directory Schema database instance on INFRADBHOST1-VIP by running the following srvctl commands:
```
ORACLE_HOME/bin/srvctl start instance -d infradb -i infradb1
ORACLE_HOME/bin/srvctl status database
```
Repeat steps 3, 4, and 5 for INFRADBHOST2-VIP.

7.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 a RAC database.

7.6.5.1 Using Oracle Directory Services Manager to Validate a Failover of a Managed Server

Follow these steps to use Oracle Directory Services Manager to validate a failover of a Managed Server:

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
```
Make a connection to Oracle Internet Directory.
Go to the Administration Console and stop the wls_ods1 Managed Server.
Go back to the Oracle Directory Services Manager page and continue your work.
The Oracle Directory Services Manager page will be disconnected.
Re-launch the Oracle Directory Services Manager page using the Oracle HTTP Server host and port again from the same browser.
Reestablish a new connection.

The current behavior is the expected behavior. Oracle Directory Services Manager failover is not transparent. You have to reestablish the connection during a WebLogic Server instance failover using Oracle Directory Services Manager.

7.6.5.2 Using Oracle Directory Services Manager to Validate a Failover of an Oracle Internet Directory Instance

Follow these steps to use Oracle Directory Services Manager to validate a failover of an Oracle Internet Directory instance:

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
```
Make a connection to the Oracle Internet Directory hardware load balancer.
Shut down one Oracle Internet Directory instance at a time.
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 displays a pop up window with a message that Oracle Internet Directory is down. Oracle Directory Services Manager will reestablish the connection to Oracle Internet Directory, but the connection may not be persistent during the failover. For additional information, see Section 7.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.

7.6.5.3 Using Oracle Directory Services Manager to Validate a RAC Failover

Follow these steps to use Oracle Directory Services Manager to validate a RAC failover:

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
```
Connect to the Oracle Internet Directory from the Oracle Directory Services Manager page.
Shut down one RAC database instance at a time.
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 a RAC failover. See Section 7.6.6.5, "Oracle Directory Services Manager Temporarily Loses Its Connection During RAC Failover" for more information about the error message that displays in Oracle Directory Services Manager during a RAC failover.

While accessing Oracle Directory Services Manager through the hardware load balancer, perform a failover on one 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 RAC database.

7.6.6 Troubleshooting Oracle Directory Services Manager

This section describes how to deal with issues involving Oracle Directory Services Manager high availability.

7.6.6.1 Dealing with Error Messages Received After Starting WebLogic Node Manager

If you receive the following error message after starting WebLogic Node Manager, follow the steps that appear below after the error message:

<Dec 15, 2008 8:40:05 PM> <Warning> <Uncaught exception in server handler:
javax.net.ssl.SSLKeyException: [Security:090482]BAD_CERTIFICATE alert was
received from stbee21.us.oracle.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.us.oracle.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.

If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit.
In the left pane of the Console, expand Servers and AdminServer (admin).
Select the Configuration > SSL > Advanced Link.
Select None for Hostname Verification.
Click Save to save the setting.
To activate these changes, in the Change Center of the Administration Console, click Activate Changes.
Restart all servers.

If the Managed Server is started in Admin mode, perform these steps:

If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit.
In the left pane of the Console, expand Servers and the name of the server that is running in ADMIN mode.
Select the Control > Start/Stop tab.
Select the name of the server.
Click Resume.
Select Yes to resume servers.

7.6.6.2 If WebLogic Node Manager Fails to Start

If WebLogic Node Manager fails to start, make sure that you have copied the following domains file from IDMHOST1 to IDMHOST2:

WL_HOME/common/nodemanager/nodemanager.domains

7.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 will see this behavior when you perform the following steps:

Oracle Directory Services Manager is deployed in a high availability active-active configuration using Oracle HTTP Server.
Display an Oracle Directory Services Manager page using the Oracle HTTP Server name and port number.
Make a connection to an LDAP server, for example, an Oracle Internet Directory server or an Oracle Virtual Directory server.
Work with the LDAP server using the current Oracle Directory Services Manager Oracle HTTP Server host and port.
Shut down one Managed Server at a time using the Oracle WebLogic Server Administration Console.
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:

In your web browser, exit the current Oracle Directory Services Manager page.
Launch a new web browser page and specify the same Oracle Directory Services Manager Oracle HTTP Server name and port.
Reestablish a new connection to the LDAP server you were working with earlier (Oracle Internet Directory or Oracle Virtual Directory).

7.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 displays the LDAP Server is down message during failover from one instance of Oracle Internet Directory to another.

The connection will be reestablished in less than a minute after the Oracle Internet Directory failover is complete, and you will be able to continue without logging in again.

7.6.6.5 Oracle Directory Services Manager Temporarily Loses Its Connection During RAC Failover

Oracle Directory Services Manager temporarily loses its connection to an Oracle Internet Directory instance that is using a RAC database during a 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 RAC failover is complete, and you will be able to continue without logging in again.

7.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 host name and port for a specific Oracle Virtual Directory instance.

7.7 Oracle Identity Federation High Availability

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

7.7.1 Oracle Identity Federation Component Architecture

Oracle Identity Federation is a self-contained, standalone federation server that enables single sign-on and authentication in a multiple-domain identity network and supports the broadest set of federation standards. This allows users to federate in heterogeneous environments and business associations, whether or not they have implemented other Oracle Identity Management products in their solution set.

It can be deployed as a multi-protocol hub acting as both an Identity Provider (IdP) and Service Provider (SP).

Acting as an SP, Oracle Identity Federation enables you to manage your resources while off loading actual authentication of users to an IdP, without having to synchronize users across security domains out of band. Once authenticated at the IdP, the SP can allow or deny access to users for the SP's applications depending upon the local access policies.

If a user no longer has an account with the IdP, the federation is terminated and cross-domain single sign-on for that user is automatically disabled. As an IdP, Oracle Identity Federation allows you to manage and authenticate local users based upon federated requests from trusted providers.

Some key features of Oracle Identity Federation include support for:

Multiple leading federation protocols such as SAML 1.x, SAML 2.0, WS-Federation, SAML 1.x/2.0 attribute sharing functionality, Liberty ID-FF 1.1/ Liberty ID-FF 1.2.
Cross-protocol single sign-on and sign-out
Affiliations, by allowing service providers to share their federation information, reducing the number of federations
X.509 certificate validation
Integration with Oracle Access Manager and Oracle Single Sign-On
Integration with Oracle Internet Directory and support for a range of authentication engines, user data repositories and relational databases
Implementing cross-site access and authentication in an environment containing both identity providers and service providers
The ability to configure, enable, and disable external sites
Accessing applications at destination sites using a single sign-on

Figure 7-10 Oracle Identity Federation Non-High Availability Architecture

Description of "Figure 7-10 Oracle Identity Federation Non-High Availability Architecture"

Figure 7-10 shows Oracle Identity Federation deployed on Oracle WebLogic Server in a non-high availability architecture and its relationship to other federation components.

Figure 7-10 shows Oracle Identity Federation as a member of Federation between other identity providers (IdP) and service providers (SP).

The Oracle Identity Federation authentication service can be configured:

To enable single sign-on access to resources protected by Oracle Single Sign-On (with the Oracle Internet Directory user repository) or Oracle Access Manager (with various repositories). Resources can include Oracle Collaboration Suite, Oracle E-Business Suite, PeopleSoft modules, and so on.
To interact with Identity and Access Management solutions such as LDAP directories, RDBMS databases, and Oracle Access Manager.

Note:
In an environment where Oracle Identity Federation and Oracle Single Sign-On both protect resources, you can configure either component to serve as the authentication mechanism when a user requests access to a protected resource. Likewise, environments containing both Oracle Identity Federation and Oracle Access Manager provide similar functionality.
For more information about Oracle Identity Federation authentication, see Oracle Fusion Middleware Administrator's Guide for Oracle Identity Federation.

7.7.1.1 Oracle Identity Federation Component Characteristics

Oracle Identity Federation is Oracle's self-contained, standalone federation server, based on J2EE standards. It enables single sign-on and authentication in a multiple-domain identity network and supports a broad set of federation standards such as SAML 1.x, SAML 2.0, WS-Federation, and SAML 1.x/2.0 attribute sharing functionality.

By default, Oracle Identity Federation is deployed as an externally staged application on Oracle WebLogic Server.

7.7.1.1.1 Runtime Processes

Oracle Identity Federation is a J2EE application that is deployed on Oracle WebLogic Server as an externally staged application. The Oracle Identity Federation server is initialized when the WebLogic Server it is deployed on starts up.

The Oracle Identity Federation application accesses the Credential Store Framework, to get the credentials to connect to the back-end servers. Once this is complete, the Oracle Identity Federation server is running and is ready to accept and serve requests.

7.7.1.1.2 Process Lifecycle

Oracle Identity Federation is deployed to an Oracle WebLogic Server as an externally managed application. By default, the Oracle WebLogic Server starts, stops, monitors and manages other lifecycle events for the Oracle Identity Federation application.

The application is initialized when the Oracle WebLogic Server it is deployed to starts up and it stops when the WebLogic Server is shut down.

WebLogic Node Manager can be configured to monitor the server process and restart it in case of failure

The Oracle Enterprise Manager Fusion Middleware Control is used to monitor as well as modify the configuration of the application.

Start ing and Stopping

Oracle Identity Federation lifecycle events can be managed using one or more of the command line tools and consoles listed below:

Oracle WebLogic Scripting Tool (WLST)
Oracle WebLogic Server Administration Console
Oracle Enterprise Manager Fusion Middleware Control
WebLogic Node Manager

7.7.1.1.3 Request Flow

Users typically access applications in multiple domains through a corporate portal. For example, Alpha Corporation could have a Portal Server in place to manage Alpha's user logins, page personalization, and so on. The portal server might consist of homegrown logic running within an application server, or it might be a commercial product. Its partner, Beta Corporation, may serve its technical database application with a "MyBeta.com" type of portal. In that case, each company would operate its own portal server.

The processing flow is as follows:

The user logs into the Alpha portal whose access is being managed by a web access management (WAM) system such as Oracle Access Manager or Oracle Single Sign-On.
The user initiates a request by clicking on a resource that is actually hosted by Beta Corporation.
The Oracle Identity Federation instance at the Alpha portal, acting as the identity provider (IdP), will send the user information to the WAM system.
The WAM system will create a session after mapping a user to an identity in its local identity store.
The WAM system will return the successful response and the session token to the Oracle Identity Federation IdP server at the Alpha portal.
Using the above information, the IdP at the Alpha portal creates a SAML identity assertion and signs it using its private signing key. This response is sent to the Oracle Identity Federation instance acting as a Service Provider (SP) at Beta Corporation.
The Oracle Identity Federation server acting as SP at Beta Corporation verifies the signed response using the IdP's public certificate associated with its signing key.
The Oracle Identity Federation service provider at Beta Corporation extracts the assertion, and creates a user session for the assertion after mapping the user session to its local authorization system.
The Oracle Identity Federation service provider sends the user's browser a redirect to the requested resource.
The user's browser sends a request to the target resource over the user session created by the service provider.

7.7.1.1.4 Configuration Artifacts

The configuration of the Oracle Identity Federation server is managed by MBeans. The configuration data for Oracle Identity Federation is stored in three main files:

config.xml: contains server-wide configuration
cot.xml: stores provider-specific configuration
datastore.xml: stores back-end data store configuration

The Oracle Identity Federation application is deployed as an EAR file by the Oracle Identity Management 11g Installer. The Oracle Identity Federation application is located under the ORACLE_HOME/fed/install/oif.ear directory.

The Oracle Identity Federation configuration artifacts are located under the DOMAIN_HOME/config/fmwconfig/servers/serverName/applications/OIF_11.1.1.2.0/configuration directory on the managed servers where the application is deployed.

Using Oracle Enterprise Manager Fusion Middleware Control to make configuration changes can help prevent inconsistent configuration across different nodes. This is especially true when the application is deployed in a high availability configuration. However, WLST scripts and JMX MBeans can also be used to configure the Oracle Identity Federation server.

7.7.1.1.5 External Dependencies

The Oracle Identity Federation server is a J2EE application that is deployed on an Oracle WebLogic Managed Server. The Oracle Identity Federation server interacts with external repositories to store configuration data, runtime transient data (message, user session) and federation data and to authenticate users. The Oracle Identity Federation server requires these repositories to be available during initialization or during runtime. These are the external components required for the Oracle Identity Federation server to function:

Oracle WebLogic Server
- Administration Server
- Managed Server
Data Repositories
- Message data store and user session data store (transient data store)
- Configuration data store
- User data store
- Federation data store
Authentication Engines
Service Provider Engines

See the following subsections for more information about how these external components function with Oracle Identity Federation.

Oracle WebLogic Server

The Oracle Identity Federation server is a J2EE application that is deployed on an Oracle WebLogic Managed Server. The server is administered and managed using the Oracle Enterprise Manager Fusion Middleware Control.

The application cannot start up if the Managed Server is not running. If the Administration Server is not available, the server will continue to run in its current state, but changes cannot be made to its configuration.

Data Repositories

The Oracle Identity Federation server uses the various external data repositories to store configuration, user session, message and federation data. The server requires these data stores to be available during initialization, runtime or both. Details of the repositories are shown below:

Message data store and user session data store (transient data store):

The Oracle Identity Federation server uses the message data store and the user session data store for storing transient data like federation protocol/session state. The message data store together with the user session data store is also referred to as a the transient data store.

Depending on the deployment option for the Oracle Identity Federation server, the transient data can either be stored in memory or in a relational database. Table 7-7 shows the relationship between the deployment option and the required transient data store type:

Table 7-7 Transient Data Store Types for Oracle identity Federation Deployment Options

Deployment Option Store Type

Non-high Availability/ Standalone

In Memory Store

Relational Database Store

High Availability

Relational Database Store
Configuration data store:

The Oracle Identity Federation application uses the configuration data store to store its configuration artifacts. Depending on the deployment option of the Oracle Identity Federation server, the configuration store can either be stored in an XML file or in a relational database.

Table 7-8 shows the relationship between the deployment option and the required configuration data store type:

Table 7-8 Configuration Data Store Types for Oracle Identity Federation Deployment Option

Deployment Option Store Type

Non-high Availability/ Standalone

XML

Relational Database Store

High Availability

Relational Database Store

The Oracle Identity Federation application connects to the configuration data store to retrieve its configuration data during the start up process. The application will fail to start up if the configuration data store is not available.
User data store:

The Oracle Identity Federation server uses the user data store to locate users after local authentication or after processing an incoming SAML Assertion and to retrieve user specific attributes. The user data repository can be either a relational database or a LDAP repository.

The Oracle Identity Federation server is certified to work with LDAP repositories such as Oracle Internet Directory, Sun Java System Directory Server, and Microsoft Active Directory, as well as with a relational database.

The role played by the user data repository depends on whether Oracle Identity Federation will be configured as an identity provider (IdP) or a service provider (SP).
- When configured as an IdP:
  - Oracle Identity Federation uses the repository to verify user identities and to build protocol assertions.
- When configured as an SP:
  - Oracle Identity Federation uses the repository to map information in received assertions to user identities at the destination, and subsequently to authorize users for access to protected resource.
  - When creating a new federation, Oracle Identity Federation uses the repository to identify the user and link the new federation to that user's account.
The Oracle Identity Federation application does not require the user data store to be available while starting up. The user data store is required at runtime.

Note:
Oracle Identity Federation is only certified to work with Oracle Database versions 10.2.0.4 and higher or Oracle Database 11.1.0.7 and higher.
Federation Data Store:

The federation data store can be XML, RDBMS or LDAP. In high availability mode, use only RDBMS or LDAP so that the federation data store is available to all members of the cluster.

The Oracle Identity Federation server uses the federation data store to persist user federation records. Identity federation is the linking of two or more accounts that a principal may hold with one or more identity providers or service providers within a given circle of trust. When users federate the otherwise isolated accounts they have with businesses (known as their local identities), they are creating a relationship between two entities, an association comprising any number of service providers and identity providers.

The Oracle Identity Federation server is certified with industry-standard LDAP repositories including Oracle Internet Directory, Sun Java System Directory Server, and Microsoft Active Directory or a relational database.

Table 7-9 shows the relationship between the deployment option and the required federation data store type:

Table 7-9 Federation Data Store Types for Oracle Identity Federation Deployment Option

Deployment Option Store Type

Non-high Availability/ Standalone

None or XML

High Availability

None, LDAP, or Relational Database Store

The federation data store is required at runtime only if persistent name identifier formats are used during protocol exchanges. The federation data store is optional at runtime if non-opaque name identifier formats are used, such as email address.

Note:
Oracle Identity Federation is only certified to work with Oracle Database versions 10.2.0.4 and higher or Oracle Database 11.1.0.7 and higher.

For more information about the federation data store for Oracle Identity Federation, see the "Federation Data Store" section in Oracle Fusion Middleware Administrator's Guide for Oracle Identity Federation.
Authentication engines:

Oracle Identity Federation IdP and SP protocol operations, such as single sign-on, federation creation, federation termination, and NameID registration, require users to be authenticated. The Oracle Identity Federation authentication module handles user authentication. The authentication module can perform two distinct roles in user authentication:
- When Oracle Identity Federation is deployed as an Identity Provider, the authentication module acts as a local authentication mechanism. The authentication module can delegate authentication or directly interact with a number of repositories and identity management solutions.
- When Oracle Identity Federation is deployed as a service provider, it uses federation protocols to have the user authenticated at a peer identity provider. Oracle Identity Federation then forwards the user to the authentication module, which propagates and creates an authenticated user session in the deployed identity management solution at the SP. In turn, this enables access to the requested protected resource.
The Oracle database, Oracle Internet Directory, Sun Java System Directory Server, and Microsoft Active Directory are some examples of supported RDBMS and LDAP repositories.

Oracle Access Manager and Oracle Single Sign On are examples of supported repositories and Identity Management solutions.

The authentication module only requires the external authentication engines to be available at runtime.
Service provider engines:

A Service Provider Integration Engine (SP Integration Engine) is used to create a user authenticated session at the Identity and Access Management (IAM) server. Oracle Identity Federation is shipped with an SP engine includes several internal plug-ins that allow it to interact with different IAM servers, such as:
- Oracle Single Sign-On
- Oracle Access Manager
- Oracle Identity Federation Test Application
Oracle Identity Federation also provides a framework to integrate with third party IAM frameworks; the customized SP Integration Module will interact with Oracle Identity Federation using internal J2EE Servlet forwards, and it will communicate with the third party IAM system to create the user authenticated session.

Any custom SP Engine modules should be deployed on each Managed Server in the cluster.

Deployment Option	Store Type
Non-high Availability/ Standalone	In Memory Store Relational Database Store
High Availability	Relational Database Store

Deployment Option	Store Type
Non-high Availability/ Standalone	XML Relational Database Store
High Availability	Relational Database Store

Deployment Option	Store Type
Non-high Availability/ Standalone	None or XML
High Availability	None, LDAP, or Relational Database Store

7.7.1.1.6 Oracle Identity Federation Log File Location

Oracle Identity Federation is a J2EE application deployed on Oracle WebLogic Server. All server related logs messages are logged in the server log file and all Oracle Identity Federation specific messages are logged into the diagnostic log file of the Oracle WebLogic Server where the application is deployed.

The default location of the Oracle WebLogic Server log file is:

WEBLOGIC_SERVER_HOME/user_projects/domains/domainName/servers/serverName/logs/
serverName-diagnostic.log

The Oracle Identity Federation log file is named serverName-diagnostic.log. For example, if the Oracle WebLogic Server name is wls_oif1, then the log file name is wls_oif1-diagnostic.log.

Use the Oracle Enterprise Manager Fusion Middleware Control to view the log files.

7.7.2 Oracle Identity Federation High Availability Concepts

This section provides an introduction to Oracle Identity Federation concepts and describes how to design and deploy a high availability environment for Oracle Identity Federation.

Listed below are a few guidelines to follow when deploying Oracle Identity Federation in a highly availability configuration:

The transient and configuration data should always be stored in a shared relational database. This is required when:
- Oracle Identity Federation acts as an IdP and the Artifact SSO profile is used. In this case, the user might interact with IdP #1 where the assertion will be created, and later when the artifact will de-referenced, the SP will connect to IdP #2. If the two Oracle Identity Federation servers are not sharing the same message store, then IdP #2 will not be able to locate the assertion for the artifact created by IdP #1.
- Oracle Identity Federation acts as an SP and the POST SSO profile is used. In the POST profile, the assertion is being carried by the user's browser, thus opening the possibility of that assertion being re-submitted to the Oracle Identity Federation SP. Because of potential replay attacks, the Oracle Identity Federation SP Server keeps a trace of the assertion it received, so that no assertion can be used twice.
- Oracle Identity Federation acts as an Authentication Query Authority, where the Oracle Identity Federation Server will answer queries from remote providers by returning assertions representing the existing sessions for a specific user at the Oracle Identity Federation Server. For this reason, the Oracle Identity Federation servers will need to share the transient session stores.
- Oracle Identity Federation acts as an IdP/Attribute Authority and has the Assertion ID Responder functionalities enabled. This feature allows remote providers to query the IdP to retrieve assertions that were already created during previous SAML flows. For that reason, the Responder needs to have access to a store containing all the assertions created.
In high availability environments, when the Oracle Identity Federation Application is not front-ended by an Oracle HTTP Serve Instance, oracle recommends:
- Enabling sticky sessions on the hardware load balancer that front-ends the Oracle Identity Federation Application.
- Sticky sessions ensue that user requests to go to the same Oracle Identity Federation server for that session
Note:
HTTP session state is used at runtime by Oracle Identity Federation when processing HTTP requests. The information stored in the HTTP session state is short-lived. The life of the information corresponds to the duration of the federation operation, such as single sign-on.
HTTP session replication replicates session information across nodes, is memory intensive, and is not recommended.

HTTP session replication is not enabled by default.

See Section 7.2.5.5.1, "Load Balancers" for a description of the features to enable in the load balancer that is required when you deploy Oracle Identity Management software in a high availability configuration.
The Oracle Identity Federation server supports two types of HTTP Session replication:
- In-memory session replication
- JDBC session replication
These are some characteristics of in-memory session replication:
- All Managed Servers running the Oracle Identity Federation application in a cluster have to be up when the session is created.
- It can slow down performance.
- If a server receives a request before session replication is completed, the server throws an error.
- To avoid this, update the parameters listed below in the config.xml file located under the DOMAIN_HOME/ config/fmwconfig/servers/serverName/applications/OIF_11.1.1.2.0/configuration directory. This must be done on all nodes running the Oracle Identity Federation Application
  - sessionreplicationenabled: Set this to true.
  - sessionreplicationtimeout: This is set to 2000 by default. Increase this if necessary.
These are some characteristics of JDBC session replication:
- Robust in nature.
- Slower in performance than in-memory session replication due to the additional overhead of database calls.
- The session persistence state is stored in a shared relational database.
- To configure Oracle WebLogic Server for JDBC session persistence see "Using a Database for Persistent Storage (JDBC persistence)" in Oracle Fusion Middleware Developing Web Applications, Servlets, and JSPs for Oracle WebLogic Server.

7.7.2.1 Oracle Identity Federation High Availability Architecture

Figure 7-11 shows the Oracle Identity Federation high availability architecture in an active-active configuration.

Figure 7-11 Oracle Identity Federation in a High Availability Architecture

Description of "Figure 7-11 Oracle Identity Federation in a High Availability Architecture"

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

On IDMHOST1, the following installations have been performed:

An Oracle Identity Federation instance has been installed in the WLS_OIF1 Managed Server. The RAC database has been configured in a JDBC multi data source to protect the instance from RAC node failure.
A WebLogic Server Administration Server has been installed. Under normal operations, this is the active Administration Server.

On IDMHOST2, the following installations have been performed:

An Oracle Identity Federation instance has been installed in the WLS_OIF2 Managed Server. The RAC database has been configured in a JDBC multi data source to protect the instance from RAC node failure.

The instances in the WLS_OIF2 Managed Server on IDMHOST2 and the instances in the WLS_OIF1 Managed Server on IDMHOST1 are configured as the CLUSTER_OIF cluster.
A WebLogic Server Administration Server has been installed. Under normal operations, this is the passive Administration Server. You make this Administration Server active if the Administration Server on IDMHOST1 becomes unavailable.

7.7.2.1.1 Star ting and Stopping the Cluster

In a high availability architecture, Oracle Identity Federation server is deployed on an Oracle WebLogic Cluster, which has at least two servers as a part of the cluster.

By default, Oracle WebLogic Server starts stops, monitors and manages the various lifecycle events for the application. The Oracle Identity Federation application leverages the high availability features of the underlying Oracle WebLogic Clusters. In case of hardware or other failures, session state is available to other cluster nodes that can resume the work of the failed node.

In a high availability environment, WebLogic Node Manager is configured to monitor the Oracle WebLogic Servers. In case of failure, Node Manager restarts the WebLogic Server.

In an high availability environment, a hardware load balancer is used to load balance requests between the multiple Oracle Identity Federation instances. If one of the Oracle Identity Federation instances fails, the load balancer detects the failure and routes requests to the surviving instances.

In high availability environments, the state and configuration information is stored a database that is shared by all the members of the cluster.

The surviving Oracle Identity Federation instances will continue to seamlessly process any unfinished transactions started on the failed instance since the state information is in the shared database and is available to all the members in the cluster.

When an Oracle Identity Federation instance fails, its database and LDAP connections are released. The surviving instances in the active-active deployment make their own connections to continue processing unfinished transactions on the failed instance.

You can use one of the following command line tools or consoles to manage the lifecycle events for the Oracle Identity Federation application:

Oracle WebLogic Server Administration Console
Oracle Enterprise Manager Fusion Middleware Control
Oracle WebLogic Scripting Tool (WLST)

7.7.2.1.2 Cluster-Wide Configuration Changes

Configuration changes made through one cluster member are propagated automatically to all others because the configuration is stored in the shared database.

HTTP session replication replicates session information across nodes and is memory intensive and is not recommended. By default, HTTP session replication is disabled.

However, if your environment requires HTTP Session Replication to be enabled, follow the steps below:

To turn session replication on or off, make updates in the weblogic.xml file on all Managed Servers where Oracle Identity Federation is deployed:

Copy the ORACLE_HOME/fed/install/oif.ear file, to a temporary location.
Extract the META-INF/weblogic.xml file from the web.war file contained in the oif.ear file
Update the parameter set persistent-store-type to replicated_if_clustered.
Save the weblogic.xml file
Re-package the Oracle Identity Federation application using the appropriate tools.
Copy the updated oif.ear file to the ORACLE_HOME/fed/install directory on all the nodes running Oracle Identity Federation.
Redeploy the updated Oracle Identity Federation application on all nodes in your environment running the application.
Restart the managed servers.

To disable HTTP Session Replication, follow the previous steps and update the parameter set persistent-store-type to memory in Step 3.

Note:

You must perform these manual steps after updating your environment with every patchset, otherwise the session replication changes are lost.

7.7.2.2 High Availability Considerations for Integration with Oracle Access Manager

This section describes the steps to take when you are integrating Oracle Identity Federation with Oracle Access Manager in a high availability topology:

In addition to deploying Oracle Identity Federation in high availability mode, Oracle Access Manager should also be deployed in high availability mode.
The Oracle Access Server SDK must be installed on every Oracle Identity Federation server in the cluster. Oracle Identity Federation must be configured to reference the directory where the SDK is installed. If the SDK is installed in the Domain Home directory, then you can reference the SDK folder using a relative path from the Domain Home folder. If the SDK is installed elsewhere, Oracle Identity Federation will need to reference the SDK folder using an absolute path.

When Oracle Identity Federation is used in a high availability environment, it is recommended that the Access Server SDK be installed under the Domain Home folder, using the same directory name on all the computers where Oracle Identity Federation is installed. This is a requirement for Oracle Identity Federation high availability integration with Oracle Access Manager because all the Oracle Identity Federation instances will share the same configuration, specifically the directory where the Access Server SDK is installed. Using a relative path allows the Oracle Identity Federation instances to share the same configuration.
Follow the instructions for integrating Oracle Access Manager as an SP integration module in the "Integrate Oracle Access Manager as an SP Integration Module" section in Oracle Fusion Middleware Administrator's Guide for Oracle Identity Federation to integrate Oracle Access Manager with the SDK instance on each Oracle Identity Federation server.
Copy over the required files to the domain library and update the WebLogic Server startup script for each Oracle Identity Federation server to add the SDK jar file to the classpath and to set the LD_LIBRARY_PATH And LD_ASSUME_KERNEL environment variables, if required. See the "Update the Oracle WebLogic Server Environment" section in Oracle Fusion Middleware Administrator's Guide for Oracle Identity Federation for more information.

7.7.2.3 Oracle Identity Federation Prerequisites

Oracle Identity Federation requires the following components:

Oracle JRockit Version 1.6.0 SDK that is bundled with the installation.
Oracle WebLogic Server that is bundled with the installation
User data store. This is typically an LDAP directory, but can optionally be a database store.
Federation data store. This is a standard LDAP directory such as Oracle Internet Directory, Microsoft Active Directory or Sun Java System Directory Server.

Note:
A user federation data store is not absolutely required for Oracle Identity Federation in all cases: it is required for Liberty 1.x and SAML 2.0 opaque persistent identifiers, but is optional for SAML 1.x, WS-Federation, and SAML 2.0 non-opaque identifiers (such as email address, subject DN, and so on).
Oracle Database version 10.2.0.4.0 and higher or 11.1.0.7 and higher for the RDBMS transient data store.
Oracle HTTP Server for proxy implementation; this is the only proxy server supported by Oracle Identity Federation, and is bundled with the installation.

Note:

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

7.7.2.3.1 Using RCU to Create Oracle Identity Federation Schemas in the Repository

Before you can install the Oracle Internet Directory instances on OIFHOST1 and OIFHOST2, you must use the Repository Creation Utility (RCU) to create the collection of schemas used by Oracle Identity Federation.

The Repository Creation Utility (RCU) ships on its own CD as part of the Oracle Fusion Middleware 11g kit.

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

Issue this command:

prompt> RCU_HOME/bin/rcu &
On the Welcome screen, click Next.
On the Create Repository screen, select the Create operation to load component schemas into an existing database.

Click Next.
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 a 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: idmedg.mycompany.com

Username: SYS

Password: The SYS user password

Role: SYSDBA

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

Create a New Prefix: idm

Components: Select Identity Management (Oracle Identity Federation - OIF). De-select all other schemas.

Click Next.
On the Schema Passwords screen, enter the passwords for the mail and additional (auxiliary) schema users.

Click Next.
On the Map Tablespaces screen, select the tablespaces for the components.
On the Summary screen, click Create.
On the Completion Summary screen, click Close.

7.7.3 Oracle Identity Federation High Availability Configuration Steps

In a high availability environment, it is recommended that Oracle WebLogic Server utilities be used for clustering, load balancing, and failover of Oracle Identity Federation instances.

Make sure that the schema database is running, then follow these steps to install.

This section describes the steps to install and configure Oracle Identity Federation instances on OIFHOST1 and OIFHOST2:

Section 7.7.3.1, "Installing Oracle WebLogic Server"
Section 7.7.3.2, "Installing Oracle Identity Federation on OIFHOST1"
Section 7.7.3.3, "Creating boot.properties for the Administration Server on OIFHOST1"
Section 7.7.3.4, "Installing Oracle Identity Federation on OIFHOST2"
Section 7.7.3.5, "Post-Installation Steps for Oracle Identity Federation"
Section 7.7.3.6, "Configuring the Load Balancer"

7.7.3.1 Installing Oracle WebLogic Server

On OIFHOST1 and OIFHOST2, start the Oracle WebLogic Server installation by running the installer executable file.

Start the Oracle WebLogic Server installer as follows:

On UNIX (Linux in the following example):
```
./wls1032_linux32.bin
```
On Windows:
```
wls1032_win32.exe
```

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

On the Welcome screen, click Next.
On the Choose Middleware Home Directory screen, choose a directory on your computer into which the Oracle WebLogic software is to be installed. This directory is called the Fusion Middleware Home directory.

For the Middleware Home Directory, specify this value:
```
/u01/app/oracle/product/fmw
```
Click Next.
On the Choose Install Type screen, the installation program displays a window in which you are prompted to indicate whether you wish to perform a complete or a custom installation.

Choose Typical or Custom (Typical is chosen in this example)

Click Next.
On the Register for Security Updates screen, enter your "My Oracle Support" UserName and Password.

Click Next.
On the Choose Install Type screen, specify the type of installation you wish to perform. Select either Typical or Custom.

Choose Typical.

Click Next.
On the Choose Product Installation Directory screen, specify the directory into which the Oracle WebLogic Server binaries should be installed.

Specify the following values for this field:
- WebLogic Server Directory:
```
/u01/app/oracle/product/fmw/wlserver_10.3
```
Click Next.
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.

Verify that the choices you made are correct. If they are not, click the Back button to make the necessary changes.

Click Next.
On the Installation Progress screen, view the installation is in progress.
On the Installation Complete screen, deselect the Run Quickstart checkbox.

Click Done.

7.7.3.2 Installing Oracle Identity Federation on OIFHOST1

Follow the steps below to install and configure the first instance of Oracle Identity Federation on OIFHOST1.

Ensure that the system, patch, kernel and other requirements are met. These are listed in the Oracle Fusion Middleware Installation Guide for Oracle Identity Management in the Oracle Fusion Middleware documentation library for the platform and version you are using.
Ensure that port number 7499 is 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 ":7499"
```
On Windows:
```
netstat -an | findstr "LISTEN" | findstr "7499"
```
If the port is in use (if the command returns output identifying the port), you must free the port.

On UNIX:

Remove the entry for port 7499 in the /etc/services file and restart the services, or restart the computer.

On Windows:

Stop the component that is using the port.
Copy the staticports.ini file from the Disk1/stage/Response directory to a temporary directory.
Edit the staticports.ini file that you copied to the temporary directory to assign the following custom port (uncomment the line where you specify the port number for Oracle Identity Federation):
```
# The OIF Server Port
OIF Server Port = 7499
```
Start the Oracle Identity Management 11g Installer as follows:

On UNIX, issue this command: runinstaller

On Windows, double-click setup.exe.

The runInstaller and setup.exe files are in the ../install/platform directory, where platform is a platform such as Linux or Win32.

This displays the Specify Oracle Inventory screen.
On the Specify Inventory Directory screen, enter values for the Oracle Inventory Directory and the Operating System Group Name. For example:

Specify the Inventory Directory: /u01/app/oraInventory

Operating System Group Name: oinstall

A dialog box appears with the following message:

"Certain actions need to be performed with root privileges before the install can continue. Please execute the script /u01/app/oraInventory/createCentralInventory.sh now from another window and then press "Ok" to continue the install. If you do not have the root privileges and wish to continue the install select the "Continue installation with local inventory" option"

Log in as root and run the "/u01/app/oraInventory/createCentralInventory.sh"

This sets the required permissions for the Oracle Inventory Directory and then brings up the Welcome screen.
Note:
The Oracle Inventory screen is not shown if an Oracle product was previously installed on the host. If the Oracle Inventory screen is not displayed for this installation, make sure to check and see:
1. If the /etc/oraInst.loc file exists
2. If the file exists, the Inventory directory listed is valid
3. The user performing the installation has write permissions for the Inventory directory
On the Welcome screen, click Next.
On the Select Installation Type screen, select Install and Configure and then click Next.
On the Prerequisite Checks screen, the installer completes the prerequisite check. If any checks fail, please fix them and restart your installation.

Click Next.
On the Select Domain screen, select Create a New Domain and specify these values:

HostName: OIFHOST1.MYCOMPANY.COM

Port: 7001

UserName: weblogic

User Password: <password for weblogic user>

Click Next.
On the Specify Installation Location screen, specify the following values:
- Oracle Middleware Home Location:
```
/u01/app/oracle/product/fmw
```
- Oracle Home Directory: oif
- WebLogic Server Directory:
```
/u01/app/oracle/product/fmw/wlserver_10.3
```
- Oracle Instance Location:
```
/u01/app/oracle/admin/oif_inst1
```
- Instance Name: oif_inst1
  
  Note:
  Ensure that the Oracle Home Location directory path for OIFHOST1 is the same as the Oracle Home Location path for OIFHOST2. For example, if the Oracle Home Location directory path for OIFHOST1 is: /u01/app/oracle/product/fmw/oif, then the Oracle Home Location directory path for OIFHOST2 must also be /u01/app/oracle/product/fmw/oif.
Click Next.
On the Specify Oracle Configuration Manager Details screen, specify the values shown in the example below:
- 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.
On the Configure Components screen, de-select all the components except Oracle Identity Federation components. The Oracle Identity Federation components include Oracle Identity Federation and Oracle HTTP Server. Select the Clustered checkbox.

Click Next.

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

Description of the illustration oifscreenshot1.gif
On the Configure Ports screen, select Specify Ports using Configuration File. Provide the path to the staticports.ini file that you copied to the temporary directory.

Click Next.
On the Specify OIF Details screen, specify these values:
- PKCS12 Password: <password>
- Confirm Password: <confirm the password entered above>
- Server Id: oif_OIFDomain
Click Next.
On the Select OIF Advanced Flow Attributes screen, specify these values:
- Authentication Type: LDAP
- User Store: LDAP
- Federation Store: LDAP
- User Session Store: RDBMS (default selection, which cannot be changed for a cluster)
- Message Store: RDBMS (default selection, which cannot be changed for a cluster.
- Configuration Store: RDBMS (default selection, which cannot be changed for a cluster.
  
  Note:
  When you choose RDBMS for the session, message, and configuration data stores during an Advanced installation, the installer creates one data source for all three data stores.
  If you want to have separate databases for each of these stores, you must configure this after the installation.
Description of the illustration oifscreenshot2.gif
On the Authentication LDAP Details screen, specify the values shown in the example below:
- LDAP Type: Select Oracle Internet Directory from the drop down.
- LDAP URL: Provide the LDAP URL to connect to your LDAP store in the following format: ldap://host:port or ldaps://host:port. For example:
```
ldaps://oid.mycompany.com:636
```
- LDAP Bind DN: cn=orcladmin
- LDAP Password: <password for orcladmin>
- User Credential ID Attribute: uid
- User Unique ID Attribute: orclguid
- Person Object Class: inetOrgPerson
Click Next.

Description of the illustration oifscreenshot3.gif
On the LDAP Attributes for User Data Store screen, specify the values shown in the example below:
- LDAP Type: Select Oracle Internet Directory from the drop down.
- LDAP URL: Provide the LDAP URL to connect to your LDAP store in the following format: ldap://host:port or ldaps://host:port. For example:
```
ldaps://oid.mycompany.com:636
```
- LDAP Bind DN: cn=orcladmin
- LDAP Password: <password for orcladmin>
- User Description Attribute: uid
- User ID Attribute: orclguid
- Person Object Class: inetOrgPerson
- Base DN: dc=us,dc=mycompany,dc=com
Click Next.

Description of the illustration oifscreenshot4.gif
On the LDAP Attributes for Federation Data Store screen, specify the values shown in the example below:
- LDAP Type: Select Oracle Internet Directory from the drop down.
- LDAP URL: Provide the LDAP URL to connect to your LDAP store in the following format: ldap://host:port or ldaps://host:port. For example:
```
ldaps://oid.mycompany.com:636
```
- LDAP Bind DN: cn=orcladmin
- LDAP Password: <password for orcladmin>
- User Federation Record Context: cn=myfed,dc=us,dc=mycompany,dc=com
- Container Object Class: This is the type of User Federation Record Context that Oracle Identity Federation should use when creating the LDAP container, if it does not exist already. If that field is empty, its value will be set to applicationprocess. For Microsoft Active Directory this field has to be set to container.
Click Next.

Description of the illustration oifscreenshot5.gif
On the Transient Store Database Details screen, specify the values shown in the example below:
- Connect String: Provide the connect string to your database. For example:
```
infradbhost1-vip.mycompany.com:1521:idmdb1^infradbhost2-vip.mycompany.com:
1521:idmdb2@idmedg.mycompany.com
```
  Note:
  The 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 RAC instances to be up. If one 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 RAC instance, and the service name provided must be configured for all the specified RAC instances.
  
  Any incorrect information entered in the RAC database connect string has to be corrected manually after the installation.
- UserName: Enter the username for the OIF Schema. For example: ha_oif
- Password: password for the oif user
Click Next.

Description of the illustration oifscreenshot6.gif
On the Installation Summary screen, review the selections to ensure that they are correct. If they are not correct, click Back to modify selections on previous screens. Then click Install.
On the Installation Progress screen, view the progress of the installation.

Once the installation is done, the oracleRoot.sh confirmation dialog box displays. This dialog box advises you that a configuration script needs to be run as root before installation can proceed. Leaving this dialog box open, open another shell window, log in as root, and run the following script:
```
/u01/app/oracle/product/fmw/oif/oracleRoot.sh
```
On the Configuration Progress screen, view the progress of the configuration.
On the Installation Complete screen, click Finish to confirm your choice to exit.

7.7.3.3 Creating boot.properties for the Administration Server on OIFHOST1

This section describes how to create a boot.properties file for the Administration Server on OIFHOST1. 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:

On OIFHOST1, go the following directory:

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

For example:

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

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.
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.
Start the Administration Server on OIFHOST1 using the startWebLogic.sh script located under the MW_HOME/user_projects/domains/domainName/bin directory.
Validate that the changes were successful by opening a web browser and accessing the following pages:
- WebLogic Server Administration Console at:
```
http://oidhost1.mycompany.com:7001/console
```
- Oracle Enterprise Manager Fusion Middleware Control at:
```
http://oidhost1.mycompany.com:7001/em
```
Log into these consoles using the weblogic user credentials.

7.7.3.4 Installing Oracle Identity Federation on OIFHOST2

Follow the steps below to install and configure the second instance of Oracle Identity Federation on OIFHOST2.

Ensure that the system, patch, kernel and other requirements are met. These are listed in the Oracle Fusion Middleware Installation Guide for Oracle Identity Management in the Oracle Fusion Middleware documentation library for the platform and version you are using.
On OIFHOST1, port 7499 was used for Oracle Identity Federation. The same port should be used for the Oracle Identity Federation instance on OIFHOST2. Therefore, ensure that port 7499 is not in use by any service on OIFHOST2 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 ":7499"
```
On Windows:
```
netstat -an | findstr "LISTEN" | findstr "7499"
```
If the port is in use (if the command returns output identifying the port), you must free the port.

On UNIX:

Remove the entry for ports 7499 in the /etc/services file and restart the services, or restart the computer.

On Windows:

Stop the component that is using the port.
Copy the staticports.ini file from the Disk1/stage/Response directory to a temporary directory.
Edit the staticports.ini file that you copied to the temporary directory to assign the following custom port (uncomment the line where you specify the port number for Oracle Identity Federation):
```
# The OIF Server Port
OIF Server Port = 7499
```
Start the Oracle Identity Management 11g Installer as follows:

On UNIX, issue this command: runinstaller

On Windows, double-click setup.exe.

The runInstaller and setup.exe files are in the ../install/platform directory, where platform is a platform such as Linux or Win32.

This displays the Specify Oracle Inventory screen.
On the Specify Inventory Directory screen, enter values for the Oracle Inventory Directory and the Operating System Group Name. For example:

Specify the Inventory Directory: /u01/app/oraInventory

Operating System Group Name: oinstall

A dialog box appears with the following message:

"Certain actions need to be performed with root privileges before the install can continue. Please execute the script /u01/app/oraInventory/createCentralInventory.sh now from another window and then press "Ok" to continue the install. If you do not have the root privileges and wish to continue the install select the "Continue installation with local inventory" option"

Log in as root and run the "/u01/app/oraInventory/createCentralInventory.sh"

This sets the required permissions for the Oracle Inventory Directory and then brings up the Welcome screen.
Note:
The Oracle Inventory screen is not shown if an Oracle product was previously installed on the host. If the Oracle Inventory screen is not displayed for this installation, make sure to check and see:
1. If the /etc/oraInst.loc file exists
2. If the file exists, the Inventory directory listed is valid
3. The user performing the installation has write permissions for the Inventory directory
On the Welcome screen, click Next.
On the Select Installation Type screen, select Install and Configure and then click Next.
On the Prerequisite Checks screen, the installer completes the prerequisite check. If any checks fail, please fix them and restart your installation.

Click Next.
On the Select Domain screen, select the Expand Cluster option and specify these values:

HostName: OIFHOST1.MYCOMPANY.COM

Port: 7001

UserName: weblogic

User Password: <password for weblogic user>

Click Next.
On the Specify Installation Location screen, specify the following values:
- Oracle Middleware Home Location:
```
/u01/app/oracle/product/fmw
```
- Oracle Home Directory: oif
- WebLogic Server Directory:
```
/u01/app/oracle/product/fmw/wlserver_10.3
```
- Oracle Instance Location:
```
/u01/app/oracle/admin/oif_inst2
```
- Instance Name: oif_inst2
  
  Note:
  Ensure that the Oracle Home Location directory path for OIFHOST1 is the same as the Oracle Home Location path for OIFHOST2. For example, if the Oracle Home Location directory path for OIFHOST1 is: /u01/app/oracle/product/fmw/oif, then the Oracle Home Location directory path for OIFHOST2 must also be /u01/app/oracle/product/fmw/oif.
Click Next.
On the Specify Oracle Configuration Manager Details screen, specify the values shown in the example below:
- 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.
On the Configure Components screen, de-select all the components except Oracle Identity Federation components. The Oracle Identity Federation components include Oracle Identity Federation and Oracle HTTP Server.

Click Next.
On the Installation Summary screen, review the selections to ensure that they are correct. If they are not correct, click Back to modify selections on previous screens. Then click Install.
On the Installation Progress screen, view the progress of the installation.

Once the installation is done, the oracleRoot.sh confirmation dialog box displays. This dialog box advises you that a configuration script needs to be run as root before installation can proceed. Leaving this dialog box open, open another shell window, log in as root, and run the following script:
```
/u01/app/oracle/product/fmw/oif/oracleRoot.sh
```
On the Configuration Progress screen, view the progress of the configuration.
On the Installation Complete screen, click Finish to confirm your choice to exit.

7.7.3.5 Post-Installation Steps for Oracle Identity Federation

Follow the post-installation steps in this section to complete the installation and configuration of the Oracle Identity Federation application.

7.7.3.5.1 Copy the Oracle Identity Federation Configuration Directory from OIFHOST1 to OIFHOST2

To copy the Oracle Identity Federation Configuration directory from OIFHOST1 to OIFHOST2:

Copy the following directory on OIFHOST1: MW_HOME/user_projects/domains/IDMDomain/config/fmwconfig/servers/wls_oif1/applications to the following location on OIFHOST2: MW_HOME/user_projects/domains/IDMDomain/config/fmwconfig/servers/wls_oif2/applications.

For example, from OIFHOST1, execute the following is command:

scp -rp MW_HOME/user_projects/domains/IDMDomain/config/fmwconfig/servers/wls_oif1/applicationsuser@OIFHOST2:/MW_HOME/user_projects/domains/IDMDomain/config/fmwconfig/servers/wls_oif2/applications

7.7.3.5.2 Start the Managed Server on OIFHOST2 in a Cluster

Follow these steps to start the newly created wls_oif2 Managed Server in a cluster on OIFHOST2:

In the left pane of the Oracle WebLogic Server Administration Console, expand Environment and select Clusters.

See the "Starting and Stopping Oracle Fusion Middleware" chapter of the Oracle Fusion Middleware Administrator's Guide for information on starting and stopping WebLogic Servers.
Click on the link for the cluster (cluster_oif) containing the Managed Server (wls_oif2) you want to stop.
Select Control.
Under Managed Server Instances in this Cluster, select the check box next to the Managed Server (wls_oif2) you want to start and click Start.
On the Cluster Life Cycle Assistant page, click Yes to confirm.

WebLogic 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 Server Status table.

7.7.3.5.3 Configure Oracle HTTP Server

Oracle HTTP Server is installed on OIFHOST1 and OIFHOST2 along with the Oracle Identity Federation server. Configure the Oracle HTTP Server by following these steps:

On OIFHOST1, edit the oif.conf file located under the INSTANCE_HOME/config/OHS/ohsName/moduleconf directory.
If the Identity Management installation is in standalone mode, uncomment and set the WebLogicHost and WebLogicPort variables to reference the WebLogic Server Managed Server where Oracle Identity Federation is running (for example: oifhost1.mycompany.com and 7499).
If the Identity Management installation is in clustered mode, uncomment and set the WebLogicCluster variable to reference the WebLogic Server Managed Servers where Oracle Identity Federation is running (for example: oifhost1.mycompany.com:7499, oifhost2.mycompany.com:7499).
Save and exit the oif.conf file.
Restart Oracle HTTP Server.

7.7.3.6 Configur ing the Load Balancer

In a high availability configuration, Oracle recommends using an external load balancer to front end and load balance requests between the various Oracle Identity Federation instances.

In high availability environments, where the Oracle Identity Federation Application is not front-ended by an Oracle HTTP Server Instance, Oracle recommends enabling sticky sessions on the hardware load balancer.

7.7.3.6.1 Load Balancer Virtual Server Name Setup

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

7.7.3.6.2 Oracle Iden tity Federation Configuration

To configure the Oracle Identity Federation application to use the load balancer VIP:

In the Oracle Enterprise Manager Fusion Middleware Control, navigate to Administration, and then Server Properties.
Change the host name and port to reflect the load balancer host and port.
In the Oracle Enterprise Manager Fusion Middleware Control, navigate to Administration, and then Identity Provider.and
Change the URL to http://LoadBalancerHost:LoadBalancerPort.
In the Oracle Enterprise Manager Fusion Middleware Control, navigate to Administration, and then Service Provider.
Change the URL to http://LoadBalancerHost:LoadBalancerPort.
Repeat these steps for each Managed Server where Oracle Identity Federation is deployed.

7.7.3.7 Validating Oracle Identity Federation High Availability

This section describes how to validate Oracle Identity Federation in a high availability configuration.

In a web browser, you will be able to access the following URLs if the configuration is correct:

http://<LoadBalancerHost>:<LoadBalancerPort>/fed/sp/metadata

http://<LoadBalancerHost>:<LoadBalancerPort>/fed/idp/metadata

Follow the instructions in the "Obtain Server Metadata" and "Add Trusted Providers" sections of Oracle Fusion Middleware Administrator's Guide for Oracle Identity Federation to import metadata from the SP into the IdP and the IDP metadata into the SP.
Go to the following URL and do a Single Sign-On operation:
```
http://<SP_Host>:<SP_port>/fed/user/testspsso
```

7.7.3.8 Enabling Oracle Identity Federation Integration with Highly Available LDAP Servers

By default, Oracle Identity Federation is not configured to be integrated with LDAP Servers deployed in a high availability configuration. To integrate Oracle Identity Federation with highly available LDAP Servers to serve as user data store, federation data store, or authentication engine, Oracle Identity Federation needs to be configured based on the LDAP server's function.

Enter the WLST script environment for Oracle Identity Federation, then set the following properties as needed:

To integrate the user data store with a highly available LDAP Server, set the userldaphaenabled boolean property from the datastore group to true; otherwise set it to false:
```
setConfigProperty('datastore','userldaphaenabled', 'true', 'boolean')
```
To integrate the federation data store with a highly available LDAP Server, set the fedldaphaenabled boolean property from the datastore group to true; otherwise set it to false:
```
setConfigProperty('datastore', 'fedldaphaenabled','true', 'boolean')
```
To integrate the LDAP authentication engine with a highly available LDAP Server, set the ldaphaenabled boolean property from the authnengines group to true; otherwise set it to false:
```
setConfigProperty('authnengines','ldaphaenabled', 'true', 'boolean')
```

7.7.4 Oracle Identity Federation Failover and Expected Behavior

This section describes steps for performing various failover operations on Oracle Identity Federation instances deployed in a high availability environment and their expected behavior. Follow the steps in this section to perform:

Oracle Identity Federation instance failover
Oracle Real Application Clusters failover

7.7.4.1 Performing an Oracle Identity Federation Failover

Follow these steps to perform a a test of a failover of an Oracle Identity Federation instance and to check the status of Oracle Identity Federation:

Note:

The testspsso URL referred to in the steps below is the Test SP SSO service that is bundled with Oracle Identity Federation 11g.

The testing service enabled by default, but can be disabled by the administrator. In a production environment, the Test SP SSO Service may be disabled.

if the Test SP SSO Service is disabled, you can use whatever service you have integrated to start the Federation SSO Flow from the SP.

Set up Oracle Identity Federation to be able to perform a federation single sign-on operation.
Start Single Sign-On operation from Oracle Identity Federation, acting as a Service Provider. One possible way to do this is to use the http://<SPhost>:<SPport>/fed/user/testspsso URL choosing Artifact profile.
On the IdP login page, shut down wls_oif1 through the Managed Server page and enter the username and password.
The Single Sign-On operation should succeed.

7.7.4.2 Performing a RAC Failover

Follow these steps to perform a RAC failover:

On one of the database hosts (infradbhost1-vip) where the Oracle Identity Federation schema is installed, use the srvctl command to stop a database instance:
```
srvctl stop instance -d db_unique_name -i inst_name_list
```
Use the srvctl command to check the status of the database:
```
srvctl status database -d db_unique_name -v
```

Perform an operation on Oracle Identity Federation:

ORACLE_INSTANCE/bin/opmnctl status ias-component=oif1

Use the srvctl command to start the database instance:

srvctl start instance -d db_unique_name -i inst_name_list

7.7.5 Troubleshooting Oracle Identity Federation High Availability

The following information may help you troubleshoot Oracle Identity Federation issues:

Oracle Identity Federation logs its messages in the Oracle WebLogic Server Managed Server log files, for example:
```
DOMAIN_HOME/servers/wls_oif1/logs/wls_oif1-diagnostic.log
```
It is recommended that you use the Oracle Enterprise Manager Fusion Control to view log files by choosing Identity And Access > OIF > Logs > View Log Messages.
Make sure that the database that you use for Oracle Identity Federation does not have old configuration data. If so, newer data may be overwritten. Delete old data in the Oracle Identity Federation configuration database tables or recreate the schema before you point Oracle Identity Federation to the database.
The host name and port in the Oracle Identity Federation server configuration should be set to the load balancer host and port - otherwise there will be errors during Single Sign-On operation.
If the clocks on the computers on which the IDP and SP are running have different times, you will see errors during Single Sign-On. Fix this by setting the system clocks to have the same time or by adjusting the server drift using the Server Properties page in the Oracle Enterprise Manager Fusion Middleware Control.
The ProviderId is a string that uniquely identifies the IDP/SP. The ProviderId for all servers in a cluster must be the same. The ProviderId is defaulted to: host:port/fed/<sp|idp> at installation time. If necessary change or set this value after installation. Do not change it again during operation.

For more information on troubleshooting Oracle Identity Federation, see Oracle Fusion Middleware Administrator's Guide for Oracle Identity Federation.

7.8 Collocated Architecture High Availability

This section describes how to design and deploy Oracle Internet Directory, Oracle Directory Integration Platform, Oracle Virtual Directory, and Oracle Directory Services Manager in collocated high availability environments. The introduction to these components is provided in previous sections of this manual.

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

7.8.1 Collocated Architecture Overview

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

Oracle Internet Directory: Section 7.3.1, "Oracle Internet Directory Component Architecture"
Oracle Virtual Directory: Section 7.4.1, "Oracle Virtual Directory Component Architecture"
Oracle Directory Integration Platform: Section 7.5.1, "Oracle Directory Integration Platform Component Architecture"
Oracle Directory Services Manager: Section 7.6.1, "Oracle Directory Services Manager Component Architecture"

Figure 7-12 shows Oracle Internet Directory, Oracle Directory Integration Platform, Oracle Virtual Directory, and Oracle Directory Services Manager collocated on a single host and deployed in a non-high availability architecture.

Figure 7-12 Collocated Components Architecture

Description of "Figure 7-12 Collocated Components Architecture"

All the components in Figure 7-12 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.

7.8.2 Collocated Architecture High Availability Deployment

Figure 7-13 shows Oracle Internet Directory, Oracle Virtual Directory, Oracle Directory Integration Platform, and Oracle Directory Services Manager collocated on IDMHOST1 and IDMHOST2 and deployed in a high availability architecture.

Figure 7-13 Collocated Components in a High Availability Architecture

Description of "Figure 7-13 Collocated Components in a High Availability Architecture"

7.8.2.1 Collocated Architecture Prerequisites

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

Oracle Internet Directory: Section 7.3.2.3, "Oracle Internet Directory Prerequisites"
Oracle Virtual Directory: Section 7.4.2.2, "Oracle Virtual Directory Prerequisites"
Oracle Directory Integration Platform: Section 7.5.2.3, "Oracle Directory Integration Platform Prerequisites"
Oracle Directory Services Manager: Section 7.6.2.3, "Oracle Directory Services Manager Prerequisites"
Oracle Identity Federation: Section 7.7.2.3, "Oracle Identity Federation Prerequisites"

7.8.2.2 Configuring Collocated Components for High Availability

This section provides the steps to install and configure Oracle Internet Directory, Oracle Directory Integration Platform, 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, make sure 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.

Install the database. For more information, see Section 7.2.3, "Installing and Configuring the Database Repository."
Install RCU. For more information, see Section 7.2.4, "Installing the Repository Creation Utility Software."
Configure the database. For more information, see Section 7.2.5, "Configuring the Database for Oracle Fusion Middleware 11g Metadata."
Run RCU to install the required schemas for Oracle Internet Directory and Oracle Identity Federation. For more information, see Section 7.3.2.3.2, "Using RCU to Create Oracle Internet Directory Schemas in the Repository" and Section 7.7.2.3.1, "Using RCU to Create Oracle Identity Federation Schemas in the Repository."
Install and configure Oracle Internet Directory on the first host. For more information, see Section 7.3.3.1.1, "Installing Oracle Internet Directory on OIDHOST1" or Section 7.3.3.2.2, "Installing Oracle Internet Directory on OIDHOST1."
Install and configure Oracle Internet Directory on the second host. For more information, see Section 7.3.3.1.3, "Installing Oracle Internet Directory on OIDHOST2" or Section 7.3.3.2.4, "Installing Oracle Internet Directory on OIDHOST2."
Install and configure Oracle Virtual Directory on the first host. For more information, see Section 7.4.3.1.1, "Installing Oracle Virtual Directory on OVDHOST1" or Section 7.4.3.2.2, "Installing the First Oracle Virtual Directory."
Install and configure Oracle Virtual Directory on the second host. For more information, see Section 7.4.3.1.2, "Installing Oracle Virtual Directory on OVDHOST2" or Section 7.4.3.2.4, "Installing an Additional Oracle Virtual Directory."
Install and configure Oracle Directory Integration Platform and Oracle Directory Services Manager on the first host. For more information, see Section 7.5.3.2, "Installing and Configuring Oracle Directory Integration Platform and Oracle Directory Services Manager on IDMHOST1."
Install and configure Oracle Directory Integration Platform and Oracle Directory Services Manager on the second host. For more information, see Section 7.5.3.4, "Installing and Configuring Oracle Directory Integration Platform and Oracle Directory Services Manager on IDMHOST2."

7.8.3 Validating the Collocated Components High Availability

See the following sections for information about validating components in the collocated high availability architectures and for information about how to failover the components and RAC.

7.8.3.1 Validation Tests

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

Oracle Internet Directory: Section 7.3.4, "Validating Oracle Internet Directory High Availability"
Oracle Virtual Directory: Section 7.4.4, "Validating Oracle Virtual Directory High Availability"
Oracle Directory Integration Platform: Section 7.6.4, "Validating Oracle Directory Services Manager High Availability"
Oracle Directory Services Manager: Section 7.6.4, "Validating Oracle Directory Services Manager High Availability"
Oracle Identity Federation: Section 7.7.3.7, "Validating Oracle Identity Federation High Availability"

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

Oracle Internet Directory: Section 7.3.5, "Oracle Internet Directory Failover and Expected Behavior"
Oracle Virtual Directory: Section 7.4.5, "Oracle Virtual Directory Failover and Expected Behavior"
Oracle Directory Integration Platform: Section 7.5.4, "Oracle Directory Integration Platform Failover and Expected Behavior"
Oracle Directory Services Manager: Section 7.6.5, "Oracle Directory Services Manager Failover and Expected Behavior"
Oracle Identity Federation: Section 7.7.4, "Oracle Identity Federation Failover and Expected Behavior"

7.8.4 Troubleshooting Collocated Components Manager High Availability

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

Oracle Internet Directory: Section 7.3.6, "Troubleshooting Oracle Internet Directory High Availability"
Oracle Virtual Directory: Section 7.4.6, "Troubleshooting Oracle Virtual Directory High Availability"
Oracle Directory Integration Platform: Section 7.5.5, "Troubleshooting Oracle Directory Integration Platform High Availability"
Oracle Directory Services Manager: Section 7.6.6, "Troubleshooting Oracle Directory Services Manager"
Oracle Identity Federation: Section 7.7.5, "Troubleshooting Oracle Identity Federation High Availability"

7.8.5 Additional Considerations for Collocated Components High Availability

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

Oracle Internet Directory: Section 7.3.7, "Additional Oracle Internet Directory High Availability Issues"
Oracle Directory Services Manager: Section 7.6.7, "Additional Considerations for Oracle Directory Services Manager High Availability"

7 Configuring High Availability for Identity Management Components

7.1 Identity Management Product Components and High Availability Concepts

7.1.1 About the 11g Oracle Identity Management Products

7.2 Prerequisites for Oracle Identity Management High Availability Configuration

7.2.1 Oracle Home Requirement

7.2.2 Database Prerequisites

7.2.3 Installing and Configuring the Database Repository

7.2.4 Installing the Repository Creation Utility Software

7.2.5 Configuring the Database for Oracle Fusion Middleware 11g Metadata

7.2.5.1 Initialization Parameters

7.2.5.2 Database Examples in This Chapter

7.2.5.3 Database Services

7.2.5.4 Verifying Transparent Application Failover (TAF)

7.2.5.5 Configuring Virtual Server Names and Ports for the Load Balancer

7.2.5.5.1 Load Balancers

7.2.5.5.2 Virtual Server Names

7.3 Oracle Internet Directory High Availability

7.3.1 Oracle Internet Directory Component Architecture

7.3.1.1 Oracle Internet Directory Component Characteristics

7.3.1.1.1 Runtime Processes

7.3.1.1.2 Process Lifecycle

7.3.1.1.3 Request Flow

7.3.1.1.4 Configuration Artifacts

7.3.1.1.5 External Dependencies

7.3.1.1.6 Oracle Internet Directory Log File

7.3.2 Oracle Internet Directory High Availability Concepts

7.3.2.1 Oracle Internet Directory High Availability Architecture

7.3.2.1.1 Starting and Stopping the Cluster

7.3.2.1.2 Cluster-Wide Configuration Changes

7.3.2.2 Protection from Failures and Expected Behavior

7.3.2.2.1 Oracle Internet Directory Process Failure

7.3.2.2.2 Expected Client Application Behavior When Failure Occurs

7.3.2.2.3 External Dependency Failure

7.3.2.3 Oracle Internet Directory Prerequisites

7.3.2.3.1 Synchronizing the Time on Oracle Internet Directory Nodes

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

7.3.2.3.3 Load Balancer Virtual Server Names for Oracle Internet Directory

7.3.3 Oracle Internet Directory High Availability Configuration Steps

7.3.3.1 Configuring Oracle Internet Directory Without a WebLogic Domain

7.3.3.1.1 Installing Oracle Internet Directory on OIDHOST1

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

7.3.3.1.3 Installing Oracle Internet Directory on OIDHOST2

7.3.3.1.4 Registering Oracle Internet Directory with a WebLogic Domain

7.3.3.2 Configuring Oracle Internet Directory With a WebLogic Domain

7.3.3.2.1 Installing Oracle WebLogic Server

7.3.3.2.2 Installing Oracle Internet Directory on OIDHOST1

7.3.3.2.3 Creating boot.properties for the Administration Server on OIDHOST1

7.3.3.2.4 Installing Oracle Internet Directory on OIDHOST2

7.3.4 Validating Oracle Internet Directory High Availability

7.3.5 Oracle Internet Directory Failover and Expected Behavior

7.3.5.1 Performing an Oracle Internet Directory Failover

7.3.5.2 Performing a RAC Failover

7.3.6 Troubleshooting Oracle Internet Directory High Availability

7.3.7 Additional Oracle Internet Directory High Availability Issues

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

7.4 Oracle Virtual Directory High Availability

7.4.1 Oracle Virtual Directory Component Architecture

7.4.1.1 Oracle Virtual Directory Runtime Considerations

7.4.1.2 Oracle Virtual Directory Component Characteristics

7.4.1.2.1 Oracle Virtual Directory Log File

7.4.2 Oracle Virtual Directory High Availability Concepts

7.4.2.1 Oracle Virtual Directory High Availability Architecture

7.4.2.1.1 Oracle Virtual Directory High Availability Connect Features

7.4.2.2 Oracle Virtual Directory Prerequisites

7.4.2.2.1 Load Balancer Virtual Server Names for Oracle Virtual Directory

7.4.3 Oracle Virtual Directory High Availability Configuration Steps

7.4.3.1 Configuring Oracle Virtual Directory Without a WebLogic Domain

7.4.3.1.1 Installing Oracle Virtual Directory on OVDHOST1

7.4.3.1.2 Installing Oracle Virtual Directory on OVDHOST2

7.4.3.1.3 Registering Oracle Virtual Directory with a WebLogic Domain

7.4.3.2 Configuring Oracle Virtual Directory With a WebLogic Domain

7.4.3.2.1 Installing Oracle WebLogic Server

7.4.3.2.2 Installing the First Oracle Virtual Directory

7.4.3.2.3 Creating boot.properties for the Administration Server on OVDHOST1

7.4.3.2.4 Installing an Additional Oracle Virtual Directory

7.4.3.3 Configuring Oracle Virtual Directory with Highly Available Data Sources

7.4.3.3.1 Configuring Oracle Virtual Directory with a RAC Database

7.4.3.3.2 Configuring Oracle Virtual Directory with LDAP

7.4.4 Validating Oracle Virtual Directory High Availability

7.4.4.1 Validating Oracle Virtual Directory High Availability Using SSL

7.3.2.1.1 Starting and S topping the Cluster

7.3.7 Additional Oracle Inter net Directory High Availability Issues

7.5.2.1.1 Starti ng and Stopping the Cluster

7.5.3 Oracle Directory I ntegration Platform and Oracle Directory Services Manager High Availability Configuration Steps

7.5.3.1 Installing the W ebLogic Administration Server on IDMHOST1 and IDMHOST2

7.5.3.2 Installing and Confi guring Oracle Directory Integration Platform and Oracle Directory Services Manager on IDMHOST1

7.5.3.4 Installing and Confi guring Oracle Directory Integration Platform and Oracle Directory Services Manager on IDMHOST2

7.5.3.5 Post-Installation Steps for Orac le Directory Integration Platform and Oracle Directory Services Manager

7.6.2.1.1 Starti ng and Stopping the Cluster