8 Configuring High Availability for Identity Management Components

The Oracle Identity Management products enable you to configure and manage the identities of users, devices, and services across diverse servers, to delegate administration of these identities, and to provide end users with self-service privileges. 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 8.1, "Identity Management Product Components and High Availability Concepts"
Section 8.2, "Prerequisites for Oracle Identity Management High Availability Configuration"
Section 8.3, "Oracle Internet Directory High Availability"
Section 8.4, "Oracle Virtual Directory High Availability"
Section 8.5, "Oracle Directory Integration Platform High Availability"
Section 8.6, "Oracle Directory Services Manager High Availability"
Section 8.7, "Collocated Architecture High Availability"
Section 8.8, "Oracle Access Manager High Availability"
Section 8.9, "Oracle Identity Manager High Availability"
Section 8.10, "Authorization Policy Manager High Availability"
Section 8.11, "Oracle Identity Navigator High Availability"
Section 8.12, "Oracle Adaptive Access Manager High Availability"
Section 8.13, "Oracle Identity Federation High Availability"
Section 8.14, "Starting and Stopping Oracle Identity Management Components"

8.1 Identity Management Product Components and High Availability Concepts

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

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

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

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

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

The application tier includes the IDMHOST1 and IDMHOST2 computers.

On IDMHOST1, the following installations have been performed:

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

On IDMHOST2, the following installations have been performed:

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

The instances in the WLS_ODS2 Managed Server on IDMHOST2 and the instances in the WLS_ODS1 Managed Server on IDMHOST1 are configured as the Cluster_ODS cluster.
An Oracle Access Manager Access Server instance has been installed in the WLS_OAM2 Managed Server.

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

The directory tier includes the OIDHOST1 and OIDHOST2 computers.

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

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 Oracle RAC database that serves as the security metadata repository. The database is enabled for server-side TAF and HA Events Notification.

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

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

8.1.1 About the 11g Oracle Identity Management Products

Table 8-1 summarizes 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 8-1 The 11g Identity Management Components and Product Suites

Product	Description	Product Suite
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 Identity Management Platform and Directory Services Suite
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 Identity Management Platform and Directory Services Suite
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 Management Platform and Directory Services Suite
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.	Oracle Identity Management Platform and Directory Services Suite
Oracle Access Manager	Oracle Access Manager 11g is the successor product to both Oracle Access Manager 10g (access only) and Oracle Single Sign-On 10g. Oracle Access Manager 11g provides a single authoritative source for all authentication and authorization services. The core service provided is the checking of valid session tokens, the requesting of credentials if the session token is invalid or missing, and the issuing of session tokens, intercepting resource requests and evaluating access control policies to control access to resources.	Oracle Identity and Access Management Suite
Oracle Identity Manager	Oracle Identity Manager is a user provisioning and administration solution that automates the process of adding, updating, and deleting user accounts from applications and directories. It also improves regulatory compliance by providing granular reports that attest to who has access to what. Oracle Identity Manager is available as a stand-alone product or as part of Oracle Identity and Access Management Suite.	Oracle Identity and Access Management Suite
Authorization Policy Manager	Authorization Policy Manager is a graphical interface tool for administering application policies. The intended users of Authorization Policy Manager are security administrators. With this tool, an administrator can view and manage policies across enterprise applications. Administrators can be specified to manage all applications running in the domain or just a subset of them.	Oracle Identity and Access Management Suite
Oracle Identity Navigator	Oracle Identity Navigator is an administrative portal designed to act as a launch pad for Oracle Identity Management products. It does not replace the individual product consoles. Rather, it allows you to access the Oracle Identity Management consoles from one site.	Oracle Identity and Access Management Suite
Oracle Adaptive Access Manager	Oracle Adaptive Access Manager (OAAM) is Oracle Identity Management's solution for web access real-time fraud detection and multifactor online authentication security for the enterprise. OAAM enables real-time blocking of fraudulent access requests, delivers advanced alerting mechanisms, and protects businesses and their customers from attacks such as phishing, Trojans, viruses, fraudulent transactions, and Man-in-the-Middle attacks.	Oracle Identity and Access Management Suite
Oracle Identity Federation	Oracle Identity Federation enables companies to provide services and share identities across their respective security domains, while providing protection from unauthorized access.	Oracle Identity Management Platform and Directory Services Suite

8.2 Prerequisites for Oracle Identity Management High Availability Configuration

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

8.2.1 Oracle Home Requirement

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

8.2.2 Database Prerequisites

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

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

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

To determine the database version, execute this query:

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

8.2.3 Installing and Configuring the Database Repository

The database used to store the metadata repository should be highly available in its own right. For maximum availability, Oracle recommends the use of an Oracle Real Application Clusters (Oracle RAC) database.

Ideally, the database will use Oracle Automatic Storage Management for the storage of data; however, this is not necessary.

If you use Oracle ASM, then Oracle ASM should be installed into its own Oracle Home and have two disk groups:

One for the Database files.
One for the Flash Recovery Area.

If you are using Oracle ASM, the best practice is to also use Oracle Managed Files.

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

Oracle Clusterware

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

Automatic Storage Management

For 10g Release 2 (10.2), see Oracle Database Oracle Clusterware and Oracle Real Application Clusters Installation Guide.
For 11g Release 1 (11.1) and later, see Oracle Real Application Clusters 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) and later, 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 (Oracle RAC) database.

See the next section for information on using RCU to load the Oracle Identity Management schemas into an Oracle 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.

8.2.4 Obtaining the Repository Creation Utility Software

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

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

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

Note:

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

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

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

8.2.4.1 Executing the Repository Creation Utility

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

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

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

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

Note:
the SOA and the MDS Schemas are automatically selected.
If the database is for Oracle Internet Directory, select Identity Management - (Oracle Internet Directory - ODS).
If the database is for Oracle Access Manager, select Identity Management - Oracle Access Manager.
If the database is for Oracle Identity Federation, select Identity Management - Oracle Identity Federation.
If the database is for Oracle Adaptive Access Manager, select Identity Management - Oracle Adaptive Access Manager.

8.2.5 Configuring the Database for Oracle Fusion Middleware 11g Metadata

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

It should be in archive log mode to facilitate backup and recovery.
Optionally, flashback should be enabled.
It should be created with the ALT32UTF8 character set.

The value of the static PROCESSES initialization parameter must be 500 or greater for Oracle Internet Directory. This value is checked by the Repository Creation Utility.

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

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

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

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

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

8.2.5.1 Database Examples in This Chapter

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

Table 8-2 Databases Used in Identity Management Configuration Examples

Component	Database Service Name	Database Instance Name
Oracle Internet Directory	oid.mycompany.com	oiddb1, oiddb2
Oracle Virtual Directory	N/A	N/A
Oracle Directory Integration Platform	oid.mycompany.com	oiddb1, oiddb2
Oracle Directory Services Manager	N/A	N/A
Oracle Access Manager	oam.mycompany.com	oamdb1, oamdb2
Oracle Identity Manager	oim.mycompany.com	oimdb1, oimdb2
Authorization Policy Manager	apm.mycompany.com	apmdb1, apmdb2
Oracle Identity Navigator	N/A	N/A
Oracle Adaptive Access Manager	oaam.mycompany.com	oaamdb1, oaamdb2
Oracle Identity Federation	oif.mycompany.com	oifdb1, oifdb2

8.2.5.2 Database Services

Oracle recommends using the Oracle Enterprise Manager Cluster Managed Services Page to create database services that client applications 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 Oracle 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 => 'idm.mycompany.com',
NETWORK_NAME => 'idm.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 idm -r idmdb1,idmdb2
```
Start the service using srvctl:
```
prompt> srvctl start service -d idmdb -s  idm
```
Note:
For more information about the SRVCTL command, see the Oracle Real Application Clusters Administration and Deployment Guide.

If you already have a service 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 => 'idm.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.

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

8.2.5.3 Verifying Transparent Application Failover (TAF)

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

After the Oracle Internet Directory process 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

8.2.5.4 Configuring Virtual Server Names and Ports for the Load Balancer

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

8.2.5.4.1 Load Balancers

All components in the Oracle Identity Management software stack require a hardware load balancer when deployed in a high availability configuration. The hardware load balancer should have the following features:

Ability to load-balance traffic to a pool of real servers through a virtual 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: The load balancer should have the ability to perform port translation, where it allows incoming requests received on one port to be routed to a server process running on a different port. For example, a request received on port 80 can be routed to port 7777.
Protocol translation: The load balancer should support protocol translation between systems running different protocols. It enables users on one network to access hosts on another network, despite differences in the native protocol stacks associated with the originating device and the targeted host. For example, incoming requests can be HTTPS, and outgoing requests can be HTTP.

This feature is recommended but not required.
SSL acceleration: SSL acceleration is a method of offloading the processor-intensive public key encryption algorithms involved in SSL transactions to a hardware accelerator.

This feature is recommended but not required.
Monitoring of ports (HTTP, HTTPS, LDAP, LDAPS)
Virtual servers and port configuration

Ability to configure virtual server names and ports on your external load balancer, and the virtual server names and ports must meet the following requirements:
- The load balancer should 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.

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

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

Component	Virtual Server Name
Oracle Internet Directory	oid.mycompany.com
Oracle Virtual Directory	ovd.mycompany.com
Oracle Identity Federation	oif.mycompany.com
Oracle Directory Services Manager Console	admin.mycompany.com
Oracle Access Manager	sso.mycompany.com
Oracle Adaptive Access Manager	oaam.mycompany.com
Oracle Identity Manager	sso.mycompany.com

8.2.5.4.2 Virtual Server Names

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

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

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

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.

oaam.myco mpany.com

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

sso.mycom pany.com

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

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

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

8.3 Oracle Internet Directory High Availability

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

This section includes the following topics:

Section 8.3.1, "Oracle Internet Directory Component Architecture"
Section 8.3.2, "Oracle Internet Directory High Availability Concepts"
Section 8.3.3, "Oracle Internet Directory High Availability Configuration Steps"
Section 8.3.4, "Validating Oracle Internet Directory High Availability"
Section 8.3.5, "Oracle Internet Directory Failover and Expected Behavior"
Section 8.3.6, "Troubleshooting Oracle Internet Directory High Availability"
Section 8.3.7, "Additional Oracle Internet Directory High Availability Issues"

8.3.1 Oracle Internet Directory Component Architecture

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

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

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

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

Description of "Figure 8-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 8-2 shows the various directory server elements and their relationships running on a single node.

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

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

LDAP is used for connections between the directory server and:

Oracle Directory Services Manager
Oracle directory replication server

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

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

Table 8-4 An Oracle internet Directory Node

Element	Description
Oracle directory server instance	Also called either an LDAP server instance or a directory server instance, it services directory requests through a single Oracle Internet Directory dispatcher process listening at specific TCP/IP ports. There can be more than one directory server instance on a node, listening on different ports.
Oracle directory replication server	Also called a replication server, it tracks and sends changes to replication servers in another Oracle Internet Directory system. There can be only one replication server on a node. You can choose whether to configure the replication server. If there are multiple instances of Oracle Internet Directory that use the same database, only one of them can be running replication. This is true even if the Oracle Internet Directory instances are on different nodes. The replication sever process is a process within Oracle Internet Directory. It only runs when replication is configured. For more information about Oracle Internet Directory replication, refer to Chapter 9, "Configuring Identity Management for Maximum High Availability.".
Oracle Database Server	Stores the directory data. Oracle strongly recommends that you dedicate a database for use by the directory. The database can reside on the same node as the directory server instances.
Oracle Process Manager and Notification Server (OPMN)	Manages Oracle Internet Directory as an Oracle Fusion Middleware component. OPMN uses the directives in the OID component snippet in `ORACLE_INSTANCE/opmn.xml` and invokes OIDMON and OIDCTL as required. The command-line utility is `opmnctl`.
OID Monitor (OIDMON)	Initiates, monitors, and terminates the LDAP server and replication server processes. When you invoke process management commands, such as oidctl or opmnctl, or when you use Fusion Middleware Control to start or stop server instances, your commands are interpreted by this process. OIDMON also monitors servers and restarts them if they have stopped running for abnormal reasons. OIDMON starts a default instance of OIDLDAPD. If the default instance of OIDLDAPD is stopped using the OIDCTL command, then OIDMON stops the instance. When OIDMON is restarted by OPMN, OIDMON restarts the default instance. All OID Monitor activity is logged in the file `ORACLE_INSTANCE/diagnostics/log/OID/component_id/oidmon-xxxx.log`. This file is on the Oracle Internet Directory server file system. OID Monitor checks the state of the servers through mechanisms provided by the operating system.
OID Control Utility (OIDCTL)	Communicates with OID Monitor by placing message data in Oracle Internet Directory server tables. This message data includes configuration parameters required to run each Oracle directory server instance. Normally used from the command line only to stop and start the replication server.

8.3.1.1 Oracle Internet Directory Component Characteristics

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

8.3.1.1.1 Runtime Processes

Oracle Internet Directory has the following runtime processes:

OIDLDAPD: This is the main process for Oracle Internet Directory. OIDLDAPD consists of a dispatcher process and a server process. The dispatcher process spawns the OIDLDAPD server processes during startup. Each OIDLDAPD dispatcher process has its own SSL and non-SSL ports for receiving requests. Every OID instance has one dispatcher and one server process by default. The number of server processes spawned for an instance is controlled by the orclserverprocs attribute.
OIDMON: OIDMON is responsible for the process control of an Oracle Internet Directory instance. This process starts, stops, and monitors Oracle Internet Directory. During startup OIDMON spawns the OIDLDAPD dispatcher process and the replication server process, if replication is configured for the instance.
Replication server process: This is a process within Oracle Internet Directory that runs only when replication is configured. The replication server process is spawned by OIDMON during startup.
OPMN: The Oracle Process Manager and Notification Server (OPMN) is a daemon process that monitors Oracle Fusion Middleware components, including Oracle Internet Directory. Oracle Enterprise Manager Fusion Middleware Control uses OPMN to stop or start instances of Oracle Internet Directory. If you stop or start Oracle Internet Directory components from the command line, you use opmnctl, the command-line interface to OPMN.

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

8.3.1.1.2 Process Lifecycle

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

Process Status Table

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

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

8.3.1.1.3 Request Flow

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

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

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

cn=componentname,cn=osdldapd,cn=subconfigsubentry

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

8.3.1.1.4 Configuration Artifacts

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

8.3.1.1.5 External Dependencies

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

8.3.1.1.6 Oracle Internet Directory Log File

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

ORACLE_INSTANCE/diagnostics/log/OID

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

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

Process	Log File Location
Directory server (oidldapd)	`ORACLE_INSTANCE`/`diagnostics/logs/ OID/componentName/oidldapd00sPID-XXXX.log` where: 00 is the instance number (00 by default) s stands for server PID is the server process identifier XXXX is a number from 0000 to orclmaxlogfilesconfigured. Once the orclmaxlogfilesconfigured value is reached, it starts over again from 0000. When it starts over, it truncates the file to 0 bytes. `ORACLE_INSTANCE/diagnostics/logs/OID/componentName/oidstackInstNumberPID.log`
LDAP dispatcher (oidldapd)	`ORACLE_INSTANCE/diagnostics/logs/ OID/componentName/oidldapd00-XXXX.log` where: 00 is the instance number (00 by default) XXXX is a number from 0000 to orclmaxlogfilesconfigured
OID Monitor (OIDMON)	`ORACLE_INSTANCE/diagnostics/logs/ OID/componentName/oidmon-XXXX.log` where: XXXX is a number from 0000 to orclmaxlogfilesconfigured
Directory replication server (oidrepld)	`ORACLE_INSTANCE/diagnostics/logs/OID/` `componentName/oidrepld-XXXX.log` where: XXXX is a number from 0000 to orclmaxlogfilesconfigured

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

8.3.2 Oracle Internet Directory High Availability Concepts

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

8.3.2.1 Oracle Internet Directory High Availability Architecture

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

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

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

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

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

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

8.3.2.1.2 Cluster-Wide Configuration Changes

Configuration changes can be done at a cluster level to any instance in the Cluster Configuration. All the nodes in the Cluster Configuration that share the same database read the same configuration information. The OIDMON process polls for configuration changes on each 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.

8.3.2.2 Protection from Failures and Expected Behavior

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

8.3.2.2.1 Oracle Internet Directory Process Failure

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

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.

8.3.2.2.2 Expected Client Application Behavior When Failure Occurs

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

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

8.3.2.2.3 External Dependency Failure

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

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

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

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

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

Oracle Internet Directory also has a mechanism to detect stale database connections, which 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.

8.3.2.3 Oracle Internet Directory Prerequisites

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

8.3.2.3.1 Synchronizing the Time on Oracle Internet Directory Nodes

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

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

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

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

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

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

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

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

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 an Oracle RAC database, specify the VIP name or one node name. Example: INFRADBHOST1-VIP or INFRADBHOST2-VIP

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

Service Name: The service name of the database. Example: oid.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.

8.3.2.3.3 Load Balancer Virtual Server Names for Oracle Internet Directory

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

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

8.3.3 Oracle Internet Directory High Availability Configuration Steps

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 Oracle RAC database repository.

8.3.3.1 Installing Oracle Fusion Middleware Components

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

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

8.3.3.1.1 Install Oracle WebLogic Server

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

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

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

Start the Oracle WebLogic Server installer.

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

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

For the Middleware Home Directory, specify this value:
```
/u01/app/oracleproduct/fmw
```
Click Next.
On the Register for Security Updates screen, enter your "My Oracle Support" User Name and Password so that you can be notified of security updates
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 Custom.

Click Next.
On the Choose Products and Components screen, select only Oracle JRockit SDK and click Next.
On the Choose Product Installation Directories screen, accept the directory /u01/app/oracle/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.

8.3.3.1.2 Installing Oracle Fusion Middleware for Identity Management

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

Note:

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

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

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

Start the installer for Oracle Fusion Middleware components.

On UNIX, issue the command:

HOST1> runInstaller

On Windows, double-click setup.exe.

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

LD_ASSUME_KERNEL
ORACLE_INSTANCE

On the Specify Inventory Directory screen, do the following:

Enter HOME/oraInventory, where HOME is the home directory of the user performing the installation (this is the recommended location).
Enter the OS group for the user performing the installation.
Click Next.

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

Click OK.

Proceed as follows:

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

Enter the OS group for the user performing the installation.

Click Next.
On the Welcome screen, click Next.
On the Select Installation Type screen, select Install-Do Not Configure.

Click Next.
On the Prerequisite Checks screen, verify that the checks complete successfully, then click Next.
On the Specify Installation Location screen, enter the following values:

MW_HOME: Enter the value of the MW_HOME, for example:
```
/u01/app/product/fmw
```
Select the previously installed Middleware Home from the drop-down list. For the Oracle Home directory, enter the directory name IDM.

Click Next.
On the Summary screen, click Install.

When prompted, on Linux and UNIX installations, execute the script oracleRoot.sh as the root user.
On the Installation Complete screen, click Finish.

8.3.3.1.3 Upgrading Oracle Identity Management to Patch Set 3

This section provides the steps to upgrade your Oracle Identity Management software to 11.1.1.4 (Patch Set 3).

Start the IDM Upgrade Installer by running ./runinstaller.
On the Welcome screen, click Next.
On the Prerequisite Checks screen, click Next.
On the Specify Install Location screen, provide the path to the Oracle Middleware Home and the name of the Oracle Home directory.
On the Installation Summary screen, validate your selections, and then click Install.
The Installation Progress screen shows the progress of the install.

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

8.3.3.2 Configuring Oracle Internet Directory Without a WebLogic Domain

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

8.3.3.2.1 Configuring 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 configure 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 Oracle Identity Management software has been installed and upgraded on OIDHOST1 as described in Section 8.3.3.1, "Installing Oracle Fusion Middleware Components."
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 OID
Oracle Internet Directory Port No = 389
# The SSL port for OID
Oracle Internet Directory (SSL) Port No = 636
```
Start the Oracle Identity Management 11g Configuration Assistant under the ORACLE_HOME/bin directory as follows:

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

On Windows, double-click config.exe
On the Welcome screen, 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 Middleware Home Location: This value is prefilled and cannot be changed.
- Oracle Home Directory:
```
/u01/app/oracle/product/fmw/idm
```
- Oracle Instance Location:
```
/u01/app/oracle/admin/oid_instance1
```
- Oracle Instance Name:
```
oid_instance1
```
  Note:
  Ensure that the Oracle Home Location directory path for OIDHOST1 is the same as the Oracle Home Location path for OIDHOST2. For example, if the Oracle Home Location directory path for OIDHOST1 is:
  /u01/app/oracle/product/fmw/idm
  
  then the Oracle Home Location directory path for OIDHOST2 must be:
  
  /u01/app/oracle/product/fmw/idm
Click Next.
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:oiddb1^infradbhost2-vip.mycompany.com:1521:oiddb2@oid.mycompany.com
```
  Note:
  The Oracle RAC database connect string information needs to be provided in the format host1:port1:instance1^host2:port2:instance2@servicename.
  During this installation, it is not required for all the Oracle RAC instances to be up. If one Oracle RAC instance is up, the installation can proceed.
  
  It is required that the information provided above is complete and accurate. Specifically, the correct host, port, and instance name must be provided for each Oracle RAC instance, and the service name provided must be configured for all the specified Oracle RAC instances.
  
  Any incorrect information entered in the Oracle RAC database connect string has to be corrected manually after the installation.
- User Name: ODS
- Password: ******
Click Next.
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.

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

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

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

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

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

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

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

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

8.3.3.2.3 Configuring Oracle Internet Directory on OIDHOST2

Make sure that the Oracle Internet Directory repository is running and then follow these steps to configure 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.
Ensure that Oracle Identity Management software has been installed and upgraded on OIDHOST2 as described in Section 8.3.3.1, "Installing Oracle Fusion Middleware Components."
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 OID
Oracle Internet Directory Port No = 389
# The SSL port for OID
Oracle Internet Directory (SSL) Port No = 636
```
Start the Oracle Identity Management 11g Configuration Assistant under the ORACLE_HOME/bin directory as follows:

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

On Windows, double-click config.exe
On the Welcome screen, 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 Middleware Home Location: This value is prefilled and cannot be changed.
- Oracle Home Directory:
```
/u01/app/oracle/product/fmw/idm
```
- Oracle Instance Location:
```
/u01/app/oracle/admin/oid_instance2
```
- Oracle Instance Name:
```
oid_instance2
```
  Note:
  Ensure that the Oracle Home Location directory path for OIDHOST2 is the same as the Oracle Home Location directory path for OIDHOST1. For example, if the Oracle Home Location directory path for OIDHOST1 is:
  /u01/app/oracle/product/fmw/idm
  
  then the Oracle Home Location directory path for OIDHOST2 must be:
  
  /u01/app/oracle/product/fmw/idm
Click Next.
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:oiddb1^infradbhost2-vip.mycompany.com:1521:oiddb2@oid.mycompany.com
```
  Note:
  The Oracle RAC database connect string information needs to be provided in the format host1:port1:instance1^host2:port2:instance2@servicename.
  During this installation, it is not required for all the Oracle RAC instances to be up. If one Oracle RAC instance is up, the installation can proceed.
  
  It is required that the information provided above is complete and accurate. Specifically, the correct host, port, and instance name must be provided for each Oracle RAC instance, and the service name provided must be configured for all the specified Oracle RAC instances.
  
  Any incorrect information entered in the Oracle RAC database connect string has to be corrected manually after the installation.
- User Name: ODS
- Password: ******
Click Next.
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.

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

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

8.3.3.3.1 Configuring 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 configure 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 Oracle Identity Management software has been installed and upgraded on OIDHOST1 as described in Section 8.3.3.1, "Installing Oracle Fusion Middleware Components."
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 OID
Oracle Internet Directory Port No = 389
# The SSL port for OID
Oracle Internet Directory (SSL) Port No = 636
```
Start the Oracle Identity Management 11g Configuration Assistant under the ORACLE_HOME/bin directory as follows:

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

On Windows, double-click config.exe
On the Welcome screen, 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: This value is prefilled and cannot be changed.
- Oracle Home Directory:
```
/u01/app/oracle/product/fmw/idm
```
- WebLogic Server Directory:
```
/u01/app/oracle/product/fmw/wlserver_10.3
```
- Oracle Instance Location:
```
/u01/app/oracle/admin/oid_inst1
```
- Oracle Instance Name:
```
oid_inst1
```
  Note:
  Ensure that the Oracle Home Location directory path for OIDHOST1 is the same as the Oracle Home Location path for OIDHOST2. For example, if the Oracle Home Location directory path for OIDHOST1 is:
  /u01/app/oracle/product/fmw/idm
  
  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.

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:oiddb1^infradbhost2-vip.mycompany.com:1521:oiddb2@oid.mycompany.com
```
  Note:
  The Oracle RAC database connect string information needs to be provided in the format host1:port1:instance1^host2:port2:instance2@servicename.
  During this installation, it is not required for all the Oracle RAC instances to be up. If one Oracle RAC instance is up, the installation can proceed.
  
  It is required that the information provided above is complete and accurate. Specifically, the correct host, port, and instance name must be provided for each Oracle RAC instance, and the service name provided must be configured for all the specified Oracle RAC instances.
  
  Any incorrect information entered in the Oracle RAC database connect string has to be corrected manually after the installation.
- User Name: ODS
- Password: ******
Click Next.
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 8.3.3.2.2, "Oracle Internet Directory Component Names Assigned by Oracle Identity Management Installer."

8.3.3.3.2 Creating boot.properties for the Administration Server on OIDHOST1

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.

8.3.3.3.3 Configuring Oracle Internet Directory on OIDHOST2

Make sure that the Oracle Internet Directory repository is running and then follow these steps to configure 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.
Ensure that Oracle Identity Management software has been installed and upgraded on OIDHOST2 as described in Section 8.3.3.1, "Installing Oracle Fusion Middleware Components."
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 OID
Oracle Internet Directory Port No = 389
# The SSL port for OID
Oracle Internet Directory (SSL) Port No = 636
```
Start the Oracle Identity Management 11g Configuration Assistant under the ORACLE_HOME/bin directory as follows:

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

On Windows, double-click config.exe
On the Welcome screen, 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: This value is prefilled and cannot be changed.
- Oracle Home Directory: idm
- WebLogic Server Directory:
```
/u01/app/oracle/product/fmw/wlserver_10.3
```
- Oracle Instance Location:
```
/u01/app/oracle/admin/oid_inst2
```
- Oracle Instance Name: oid_inst2
  
  Note:
  Ensure that the Oracle Home Location directory path for OIDHOST1 is the same as the Oracle Home Location path for OIDHOST2. For example, if the Oracle Home Location directory path for OIDHOST1 is:
  /u01/app/oracle/product/fmw/idm
  
  then the Oracle Home Location directory path for OIDHOST2 must be:
  
  /u01/app/oracle/product/fmw/idm
Click Next.
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:oiddb1^infradbhost2-vip.mycompany.com:1521:oiddb2@oid.mycompany.com
```
  Note:
  The Oracle RAC database connect string information needs to be provided in the format host1:port1:instance1^host2:port2:instance2@servicename.
  During this installation, it is not required for all the Oracle RAC instances to be up. If one Oracle RAC instance is up, the installation can proceed.
  
  It is required that the information provided above is complete and accurate. Specifically, the correct host, port, and instance name must be provided for each Oracle RAC instance, and the service name provided must be configured for all the specified Oracle RAC instances.
  
  Any incorrect information entered in the Oracle RAC database connect string has to be corrected manually after the installation.
- User Name: ODS
- Password: ******
Click Next.
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.

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

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

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

8.3.5.2 Performing an Oracle RAC Failover

Follow these steps to perform an Oracle 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

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

8.3.7 Additional Oracle Inter net Directory High Availability Issues

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

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

You can change the 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.

8.4 Oracle Virtual Directory High Availability

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

This section includes the following topics:

Section 8.4.1, "Oracle Virtual Directory Component Architecture"
Section 8.4.2, "Oracle Virtual Directory High Availability Concepts"
Section 8.4.3, "Oracle Virtual Directory High Availability Configuration Steps"
Section 8.4.4, "Validating Oracle Virtual Directory High Availability"
Section 8.4.5, "Oracle Virtual Directory Failover and Expected Behavior"
Section 8.4.6, "Troubleshooting Oracle Virtual Directory High Availability"

8.4.1 Oracle Virtual Directory Component Architecture

Oracle Virtual Directory is an LDAP version 3 enabled service that provides virtualized abstraction of one or more enterprise data sources into a single directory view. Oracle Virtual Directory provides the ability to integrate LDAP-aware applications into diverse directory environments while minimizing or eliminating the need to change either the infrastructure or the applications. Oracle Virtual Directory supports a diverse set of clients, such as Web Applications and portals, and it can connect to directories, databases and Web Services as shown in Figure 8-4.

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

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

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

8.4.1.1 Oracle Virtual Directory Runtime Considerations

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

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

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

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

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

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

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

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

8.4.1.2 Oracle Virtual Directory Component Characteristics

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

server.os_xml:

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

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

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

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

8.4.1.2.1 Oracle Virtual Directory Log File

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

ORACLE_INSTANCE/diagnostics/logs/OVD/OVDComponentName/

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

8.4.2 Oracle Virtual Directory High Availability Concepts

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

8.4.2.1 Oracle Virtual Directory High Availability Architecture

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

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

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

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

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

8.4.2.1.1 Oracle Virtual Directory High Availability Connect Features

Oracle Virtual Directory offers multiple high availability capabilities, including:

Fault Tolerance and Failover: Oracle Virtual Directories provide fault tolerance in two forms:
- They can be configured in fault tolerant configurations.
- They can manage flow to fault tolerant proxied sources.
Multiple Oracle Virtual Directories can be quickly deployed 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 (Oracle RAC). See Section 4.1.5, "JDBC Clients" for more information about using Oracle Virtual Directory with Oracle 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 8.4.6, "Troubleshooting Oracle Virtual Directory High Availability".

8.4.2.2 Oracle Virtual Directory Prerequisites

This section describes prerequisites for Oracle Virtual Directory.

Note:

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

8.4.2.2.1 Load Balancer Virtual Server Names for Oracle Virtual Directory

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

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

8.4.3 Oracle Virtual Directory High Availability Configuration Steps

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

Since Oracle Directory Services Manager and Oracle Enterprise Manager Fusion Middleware Control are required to manage Oracle Virtual Directory effectively, it is recommended that Oracle Virtual Directory be deployed as part of an Oracle WebLogic Server domain. For information on configuring Oracle Virtual Directory and Oracle Directory Services Manager in a collocated configuration, see Section 8.7, "Collocated Architecture High Availability."

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

8.4.3.1 Configuring Oracle Virtual Directory Without a WebLogic Domain

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

Note:

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

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

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

8.4.3.1.1 Configuring Oracle Virtual Directory on OVDHOST1

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

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 Oracle Identity Management software has been installed and upgraded on OVDHOST1 as described in Section 8.3.3.1, "Installing Oracle Fusion Middleware Components."
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 LDAP port for OVD
Oracle Virtual Directory (Non-SSL) Port No for LDAP= 6501
# The SSL LDAP Port for OVD
Oracle Virtual Directory (SSL) Port No for LDAP = 7501
```
Start the Oracle Identity Management 11g Configuration Assistant located under the ORACLE_HOME/bin directory as follows:

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

On Windows, double-click config.exe
On the Welcome screen, 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 Middleware Home Location: This value is prefilled and cannot be changed.
- Oracle Home Directory:
```
/u01/app/oracle/product/fmw/idm_1
```
- Oracle Instance Location:
```
/u01/app/oracle/admin/ora_inst1
```
- Oracle Instance Name:
```
ora_inst1
```
  Note:
  Ensure that the Oracle Home Location directory path for OVDHOST1 is the same as the Oracle Home Location directory path for OVDHOST2. For example, if the Oracle Home Location directory path for OVDHOST1 is:
  /u01/app/oracle/product/fmw/idm_1
  
  then the Oracle Home Location directory path for OVDHOST2 must be:
  
  /u01/app/oracle/product/fmw/idm_1
Click Next.
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.

8.4.3.1.2 Configuring Oracle Virtual Directory on OVDHOST2

Follow these steps to configure 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.
Ensure that Oracle Identity Management software has been installed and upgraded on OVDHOST2 as described in Section 8.3.3.1, "Installing Oracle Fusion Middleware Components."
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 LDAP port for OVD
Oracle Virtual Directory (Non-SSL) Port No for LDAP = 6501
# The SSL LDAP Port for OVD
Oracle Virtual Directory (SSL) Port No for LDAP = 7501
```
Start the Oracle Identity Management 11g Configuration Assistant located under the ORACLE_HOME/bin directory as follows:

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

On Windows, double-click config.exe
On the Welcome screen, 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 Middleware Home Location: This value is prefilled and cannot be changed.
- Oracle Home Directory:
```
/u01/app/oracle/product/fmw/idm_1
```
- Oracle Instance Location:
```
/u01/app/oracle/admin/ora_inst2
```
- Oracle Instance Name:
```
ora_inst2
```
  Note:
  Ensure that the Oracle Home Location directory path for OVDHOST2 is the same as the Oracle Home Location directory path for OVDHOST1. For example, if the Oracle Home Location directory path for OVDHOST1 is:
  /u01/app/oracle/product/fmw/idm_1
  
  then the Oracle Home Location directory path for OVDHOST2 must be:
  
  /u01/app/oracle/product/fmw/idm_1
Click Next.
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.

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

8.4.3.2 Configuring Oracle Virtual Directory With a WebLogic Domain

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

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

8.4.3.2.1 Configuring Oracle Virtual Directory on OVDHOST1

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

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 Oracle Identity Management software has been installed and upgraded on OVDHOST1 as described in Section 8.3.3.1, "Installing Oracle Fusion Middleware Components."
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 LDAP port for OVD
Oracle Virtual Directory (Non-SSL) Port No for LDAP = 6501
# The SSL LDAP port for OVD
Oracle Virtual Directory (SSL) Port No for LDAP = 7501
```
Start the Oracle Identity Management 11g Configuration Assistant located under the ORACLE_HOME/bin directory as follows:

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

On Windows, double-click config.exe
On the Welcome screen, 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.

8.4.3.2.2 Creating boot.properties for the Administration Server on OVDHOST1

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

Follow these steps to create the boot.properties file:

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.

8.4.3.2.3 Configuring Oracle Virtual Directory on OVDHOST2

Follow these steps to configure 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.
Ensure that Oracle Identity Management software has been installed and upgraded on OVDHOST2 as described in Section 8.3.3.1, "Installing Oracle Fusion Middleware Components."
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 LDAP port for OVD
Oracle Virtual Directory (Non-SSL) Port No for LDAP = 6501
# The SSL LDAP port for OVD
Oracle Virtual Directory (SSL) Port No for LDAP = 7501
```
Start the Oracle Identity Management 11g Configuration Assistant located under the ORACLE_HOME/bin directory as follows:

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

On Windows, double-click config.exe
On the Welcome screen, 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.

8.4.3.3 Configuring Oracle Virtual Directory with Highly Available Data Sources

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

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

Note:

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

8.4.3.3.1 Configuring Oracle Virtual Directory with an Oracle RAC Database

In an Oracle Virtual Directory high availability environment with an Oracle RAC database 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 Oracle RAC databases, see the "Creating Database Adapters for RAC Databases" section of Oracle Fusion Middleware Administrator's Guide for Oracle Virtual Directory.

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

8.4.3.3.2 Configuring Oracle Virtual Directory with LDAP

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

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

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

8.4.4 Validating Oracle Virtual Directory High Availability

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

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

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

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.

8.4.4.1 Validating Oracle Virtual Directory High Availability Using SSL

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

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 8.4.4, "Validating Oracle Virtual Directory High Availability" but use the ldapbind command shown below to validate the high availability setup of Oracle Virtual Directory on OVDHOST1 and OVDHOST2. Use the Oracle Wallet from step 3 while 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.

8.4.5 Oracle Virtual Directory Failover and Expected Behavior

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

8.4.5.1 Performing an Oracle Virtual Directory Failover

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

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

8.4.5.2 Performing an Oracle RAC Failover

Follow these steps to perform an Oracle 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 Oracle RAC failover fails. However, subsequent search requests succeed without any issues.

8.4.6 Troubleshooting Oracle Virtual Directory High Availability

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

ORACLE_INSTANCE/diagnostics/log/OVD/<OVDComponentName>

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

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.

8.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 load balancer name that front-ends more than one LDAP server, it imports only one of the LDAP server's certificates. This causes a problem when the Oracle Virtual Directory server's request is routed to the LDAP server, whose certificate is not trusted.

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

8.5 Oracle Directory Integration Platform High Availability

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

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

This section includes the following topics:

Section 8.5.1, "Oracle Directory Integration Platform Component Architecture"
Section 8.5.2, "Oracle Directory Integration Platform High Availability Concepts"
Section 8.5.3, "Oracle Directory Integration Platform and Oracle Directory Services Manager High Availability Configuration Steps"
Section 8.5.4, "Oracle Directory Integration Platform Failover and Expected Behavior"
Section 8.5.5, "Troubleshooting Oracle Directory Integration Platform High Availability"

8.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 8-6 shows the Oracle Directory Integration Platform architecture.

Figure 8-6 Oracle Directory Integration Platform Architecture

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

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

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

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

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

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

8.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/
fmwconfig/servers/serverName/applications/DIP_11.1.1.2.0/configuration

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

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

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

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

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

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

8.5.2.1 Oracle Directory Integration Platform High Availability Architecture

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

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

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

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

On IDMHOST1, the following installations have been performed:

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

On IDMHOST2, the following installations have been performed:

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

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

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

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

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

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

8.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 Administrator's Guide for Oracle Directory Integration Platform for more information about the manageDIPServerConfig tool.

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

8.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 8.3.2.3, "Oracle Internet Directory Prerequisites"
Section 8.3.3, "Oracle Internet Directory High Availability Configuration Steps"

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

Section 8.5.3.1, "Configuring Oracle Directory Integration Platform and Oracle Directory Services Manager on IDMHOST1"
Section 8.5.3.2, "Creating boot.properties for the Administration Server on IDMHOST1"
Section 8.5.3.3, "Configuring Oracle Directory Integration Platform and Oracle Directory Services Manager on IDMHOST2"
Section 8.5.3.4, "Post-Installation Steps for Oracle Directory Integration Platform and Oracle Directory Services Manager"
Section 8.5.3.5, "Installing Oracle Fusion Middleware Components on WEBHOST1 and WEBHOST2"
Section 8.5.3.6, "Configuring 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.

8.5.3.1 Confi guring Oracle Directory Integration Platform and Oracle Directory Services Manager on IDMHOST1

Follow these steps to 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 Oracle Identity Management software has been installed and upgraded on IDMHOST1 as described in Section 8.3.3.1, "Installing Oracle Fusion Middleware Components."
Ensure that port 7006 is not in use by any service on IDMHOST1 by issuing these commands for the operating system you are using. If a port is not in use, no output is returned from the command.

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 port
ODS Server Port No = 7006
```
Start the Oracle Identity Management 11g Configuration Assistant located under the ORACLE_HOME/bin directory as follows:

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

On Windows, double-click config.exe
On the Welcome screen, 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: This value is prefilled and cannot be changed.
- Oracle Home Directory: This value is prefilled and cannot be changed)
```
ods
```
- WebLogic Server Directory:
```
/u01/app/oracle/product/fmw/wlserver_10.3
```
- Oracle Instance Location:
```
/u01/app/oracle/admin/ods_instance1
```
- Oracle Instance Name:
```
ods_instance1
```
Click Next.
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:oiddb1^infradbhost2-vip.mycompany.com:1521:oiddb2@oid.mycompany.com
```
  Note:
  The Oracle RAC database connect string information needs to be provided in the format host1:port1:instance1^host2:port2:instance2@servicename.
  During this installation, it is not required for all the Oracle RAC instances to be up. If one Oracle RAC instance is up, the installation can proceed.
  
  It is required that the information provided above is complete and accurate. Specifically, the correct host, port, and instance name must be provided for each Oracle RAC instance, and the service name provided must be configured for all the specified Oracle RAC instances.
  
  Any incorrect information entered in the Oracle RAC database connect string has to be corrected manually after the installation.
- User Name: ODSSM
- Password: ******
Click Next.
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.

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

8.5.3.3 Confi guring Oracle Directory Integration Platform and Oracle Directory Services Manager on IDMHOST2

Follow these steps to configure Oracle Directory Integration Platform and Oracle Directory Services Manager 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.
Ensure that Oracle Identity Management software has been installed and upgraded on IDMHOST2 as described in Section 8.3.3.1, "Installing Oracle Fusion Middleware Components."
Start the Oracle Identity Management 11g Configuration Assistant located under the ORACLE_HOME/bin directory as follows:

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

On Windows, double-click config.exe
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: This value is prefilled and cannot be changed.
```
/u01/app/oracle/product/fmw
```
- Oracle Home Directory: This value is prefilled and cannot be changed.
```
ods
```
- WebLogic Server Directory:
```
/u01/app/oracle/product/fmw/wlserver_10.3
```
- Oracle Instance Location:
```
/u01/app/oracle/admin/ods_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.

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

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

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

8.5.3.5 Installing Oracle Fusion Middleware Components on WEBHOST1 and WEBHOST2

This section describes how to install the required binaries for the Oracle Home (ORACLE_HOME) for Oracle HTTP Server.

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

8.5.3.5.1 Installing Oracle HTTP Server for the Web Tier

This section describes how to install Oracle HTTP Server.

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

Start the installer for Oracle Web Tier components.

HOST1> ./runInstaller

Then perform these installation steps:

On the Prerequisite Checks screen, verify that the checks complete successfully, then click Next.
On the Specify Installation Location screen, enter the following values:

MW_HOME: Enter the value of the MW_HOME, for example:
```
/u01/app/product/fmw
```
Select the previously installed Middleware Home from the drop-down list. For the Oracle HTTP Server Oracle Home (OHS_ORACLE_HOME) directory, enter the directory name WEB.

Click Next.
On the Summary screen, click Install.

When prompted, on Linux and UNIX installations, execute the script oracleRoot.sh as the root user.
On the Installation Complete screen, click Finish.

8.5.3.5.2 Upgrading the Oracle HTTP Server Oracle Home to Patch Set 3

This section provides the steps to upgrade your Oracle HTTP Server software to 11.1.1.4 (Patch Set 3).

Start the Web Tier Upgrade Installer by running ./runinstaller.
On the Welcome screen, click Next.
On the Prerequisite Checks screen, click Next.
On the Specify Install Location screen, provide the path to the Oracle Middleware Home and the name of the Oracle HTTP Server Oracle Home directory.
On the Installation Summary screen, validate your selections, and then click Install.
The Installation Progress screen shows the progress of the install.

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

8.5.3.6 Configuring Oracle HTTP Server on WEBHOST1 and WEBHOST2

This section describes how to configure 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 Oracle Web Tier in the Oracle Fusion Middleware documentation library for the platform and version you are using.
Ensure that Oracle HTTP Server software has been installed and upgraded on WEBHOST1 and WEBHOST2 as described in Section 8.5.3.5, "Installing Oracle Fusion Middleware Components on WEBHOST1 and WEBHOST2."
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 http_main port for ohs component
OHS Port = 7777
```
Start the Configuration Assistant for Oracle Fusion Middleware 11g Web Tier utilities located under the ORACLE_HOME/bin directory as follows:

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

On Windows, double-click config.exe
On the Welcome screen, 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.

8.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 8.2.5.4, "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>
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

#AdminServer and EM
<Location /console>
SetHandler weblogic-handler
WebLogicHost VIP1
WeblogicPort 7001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /consolehelp>
SetHandler weblogic-handler
WebLogicHost VIP1
WeblogicPort 7001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /em>
SetHandler weblogic-handler
WebLogicHost VIP1
WeblogicPort 7001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

<Location /odsm-config>
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 Administrator's Guide for Oracle Directory Integration Platform.

8.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 Oracle RAC node takes over any remaining processes. There may be innocuous errors in the Managed Servers logs during an Oracle RAC failover, as discussed in Section 8.5.5, "Troubleshooting Oracle Directory Integration Platform High Availability."

8.5.5 Troubleshooting Oracle Directory Integration Platform High Availability

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

8.5.5.1 Managed Server Log File Exceptions Received for Oracle Directory Integration Platform During an Oracle RAC Failover

During an Oracle RAC failover, exceptions similar to the ones below are seen in the Managed Server log files running the Oracle Directory Integration Platform application. These errors are thrown when the multi data sources configured on the WebLogic Server platform try to verify the health of the Oracle RAC database instances during failover. These are innocuous errors 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 an Oracle RAC failover, there will be no Oracle Directory Integration Platform down time if one Oracle RAC instance is running at all times.

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

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

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

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

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

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

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

8.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 Administrator's Guide for Oracle Directory Integration Platform for more information about the manageDIPServerConfig tool.

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

8.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 8.5, "Oracle Directory Integration Platform High Availability" for more information about Oracle Directory Integration Platform.

This section includes the following topics:

Section 8.6.1, "Oracle Directory Services Manager Component Architecture"
Section 8.6.2, "Oracle Directory Services Manager High Availability Concepts"
Section 8.6.3, "Oracle Directory Services Manager High Availability Configuration Steps"
Section 8.6.4, "Validating Oracle Directory Services Manager High Availability"
Section 8.6.5, "Oracle Directory Services Manager Failover and Expected Behavior"
Section 8.6.6, "Troubleshooting Oracle Directory Services Manager"
Section 8.6.7, "Additional Considerations for Oracle Directory Services Manager High Availability"

8.6.1 Oracle Directory Services Manager Component Architecture

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

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

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

Figure 8-8 Oracle Directory Services Manager Architecture

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

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

8.6.1.1 Oracle Directory Services Manager Component Characteristics

Oracle Directory Services Manager is an Oracle Application Development Framework (ADF)-based J2EE application that is deployed on top of the Oracle WebLogic Server. 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.

8.6.1.1.1 Lifecycle Management

The lifecycle events for the Oracle Directory Services Manager application can be managed using one or more of the command line tools and consoles listed below:

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

8.6.1.1.2 Oracle Directory Services Manager Log File

Oracle Directory Services Manager messages are logged in the server log file of the Oracle WebLogic Server where it is running. The default location of the server log is:

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

8.6.2 Oracle Directory Services Manager High Availability Concepts

This section provides conceptual information about using Oracle Directory Services Manager in a high availability configuration.

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

8.6.2.1 Oracle Directory Services Manager High Availability Architecture

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

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

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

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

On IDMHOST1, the following installations have been performed:

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

On IDMHOST2, the following installations have been performed:

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

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

8.6.2.1.1 Starti ng and Stopping the Cluster

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

8.6.2.2.1 Process Failure

In a high availability environment, the Oracle Directory Services Manager applications are deployed on an Oracle WebLogic Server cluster comprised of at least two WebLogic instances.

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

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.

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

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

8.6.2.3 Oracle Directory Services Manager Prerequisites

This section describes prerequisites for setting up Oracle Directory Services Manager in the high availability architecture.

Note:

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

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 8.2.4, "Obtaining the Repository Creation Utility Software"
- Section 8.2.5, "Configuring the Database for Oracle Fusion Middleware 11g Metadata"
Load balancers and virtual hosts

See Section 8.2.5.4, "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 8.3.2.3, "Oracle Internet Directory Prerequisites"
- Section 8.3.3, "Oracle Internet Directory High Availability Configuration Steps"

8.6.3 Oracle Directory Services Manager High Availability Configuration Steps

See Section 8.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 8-9.

8.6.4 Validating Oracle Directory Services Manager High Availability

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

8.6.4.1 Performing a WebLogic Server Instance Failover

While you are accessing Oracle Directory Services Manager through Oracle HTTP Server, you can use the steps in this section to fail over a WebLogic Server instance and validate that Oracle Directory Services Manager is still accessible.

The Oracle HTTP Server virtual server name in this example is:

http://admin.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.

8.6.4.2 Performing an Oracle RAC Database Failover

While you are accessing Oracle Directory Services Manager through the load balancing router, you can follow the steps in this section to fail over one Oracle RAC database instance at a time and ensure that Oracle Directory Services Manager is still functional. This example checks Oracle Directory Services Manager as well as Oracle Internet Directory access to the database.

The Oracle HTTP Server virtual server name in this example is:

http://admin.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.

8.6.5 Oracle Directory Services Manager Failover and Expected Behavior

This section provides steps for using Oracle Directory Services Manager to validate a failover of a Managed Server, to validate a failover of an Oracle Internet Directory instance, and to validate a failover of an Oracle RAC database.

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

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.

8.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 8.6.6.4, "Oracle Directory Services Manager Displays "LDAP Server is down" Message During Oracle Internet Directory Failover."

While accessing Oracle Directory Services Manager, fail over the Oracle Internet Directory instances one at a time and ensure the LDAP store is still accessible. Oracle Directory Services Manager might not have a persistent connection to Oracle Internet Directory.

8.6.5.3 Using Oracle Directory Services Manager to Validate an Oracle RAC Failover

Follow these steps to use Oracle Directory Services Manager to validate an Oracle 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 Oracle 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 an Oracle RAC failover. See Section 8.6.6.5, "Oracle Directory Services Manager Temporarily Loses Its Connection During Oracle RAC Failover" for more information about the error message that displays in Oracle Directory Services Manager during an Oracle RAC failover.

While accessing Oracle Directory Services Manager through the hardware load balancer, perform a failover on one Oracle RAC database instance at a time and ensure that Oracle Directory Services Manager is still functional. This will check Oracle Directory Services Manager as well as Oracle Internet Directory access to the Oracle RAC database.

8.6.6 Troubleshooting Oracle Directory Services Manager

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

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

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

8.6.6.3 Oracle Directory Services Manager Failover Using Oracle HTTP Server is Not Transparent

When you perform an Oracle Directory Services Manager failover using Oracle HTTP Server, the failover is not transparent. You 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).

8.6.6.4 Oracle Directory Services Manager Displays "LDAP Server is down" Message During Oracle Internet Directory Failover

In a high availability configuration where Oracle Directory Services Manager is connected to Oracle Internet Directory through a load balancer, Oracle Directory Services Manager 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.

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

Oracle Directory Services Manager temporarily loses its connection to an Oracle Internet Directory instance that is using an Oracle RAC database during an Oracle RAC failover. Oracle Directory Services Manager may display the message Failure accessing Oracle database (oracle errcode=errcode), where errcode is one of the following values: 3113, 3114, 1092, 28, 1041, or 1012.

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

8.6.7 Additional Considerations for Oracle Directory Services Manager High Availability

When using Oracle Directory Services Manager to manage an Oracle Internet Directory cluster, use the load balancer virtual address as the connect string. However, when using Oracle Directory Services Manager to manage an Oracle Virtual Directory cluster, you must specify the host name and port for a specific Oracle Virtual Directory instance.

8.7 Collocated Architecture High Availability

This section describes how to design and deploy Oracle Internet Directory, Oracle Directory Integration Platform, 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.

This section includes the following topics:

Section 8.7.1, "Collocated Architecture Overview"
Section 8.7.2, "Collocated Architecture High Availability Deployment"
Section 8.7.3, "Validating the Collocated Components High Availability"
Section 8.7.4, "Troubleshooting Collocated Components Manager High Availability"
Section 8.7.5, "Additional Considerations for Collocated Components High Availability"

8.7.1 Collocated Architecture Overview

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

Oracle Internet Directory: Section 8.3.1, "Oracle Internet Directory Component Architecture"
Oracle Virtual Directory: Section 8.4.1, "Oracle Virtual Directory Component Architecture"
Oracle Directory Integration Platform: Section 8.5.1, "Oracle Directory Integration Platform Component Architecture"
Oracle Directory Services Manager: Section 8.6.1, "Oracle Directory Services Manager Component Architecture"

Figure 8-10 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 8-10 Collocated Components Architecture

Description of "Figure 8-10 Collocated Components Architecture"

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

8.7.2 Collocated Architecture High Availability Deployment

Figure 8-11 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 8-11 Collocated Components in a High Availability Architecture

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

8.7.2.1 Collocated Architecture Prerequisites

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

Oracle Internet Directory: Section 8.3.2.3, "Oracle Internet Directory Prerequisites"
Oracle Virtual Directory: Section 8.4.2.2, "Oracle Virtual Directory Prerequisites"
Oracle Directory Integration Platform: Section 8.5.2.3, "Oracle Directory Integration Platform Prerequisites"
Oracle Directory Services Manager: Section 8.6.2.3, "Oracle Directory Services Manager Prerequisites"
Oracle Identity Federation: Section 8.13.2.3, "Oracle Identity Federation Prerequisites"

8.7.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 8.2.3, "Installing and Configuring the Database Repository."
Install RCU. For more information, see Section 8.2.4, "Obtaining the Repository Creation Utility Software."
Configure the database. For more information, see Section 8.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 8.3.2.3.2, "Using RCU to Create Oracle Internet Directory Schemas in the Repository" and Section 8.13.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 8.3.3.2.1, "Configuring Oracle Internet Directory on OIDHOST1" or Section 8.3.3.3.1, "Configuring Oracle Internet Directory on OIDHOST1."
Install and configure Oracle Internet Directory on the second host. For more information, see Section 8.3.3.2.3, "Configuring Oracle Internet Directory on OIDHOST2" or Section 8.3.3.3.3, "Configuring Oracle Internet Directory on OIDHOST2."
Install and configure Oracle Virtual Directory on the first host. For more information, see Section 8.4.3.1.1, "Configuring Oracle Virtual Directory on OVDHOST1" or Section 8.4.3.2.1, "Configuring Oracle Virtual Directory on OVDHOST1."
Install and configure Oracle Virtual Directory on the second host. For more information, see Section 8.4.3.1.2, "Configuring Oracle Virtual Directory on OVDHOST2" or Section 8.4.3.2.3, "Configuring Oracle Virtual Directory on OVDHOST2."
Install and configure Oracle Directory Integration Platform and Oracle Directory Services Manager on the first host. For more information, see Section 8.5.3.1, "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 8.5.3.3, "Configuring Oracle Directory Integration Platform and Oracle Directory Services Manager on IDMHOST2."

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

8.7.3.1 Validation Tests

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

Oracle Internet Directory: Section 8.3.4, "Validating Oracle Internet Directory High Availability"
Oracle Virtual Directory: Section 8.4.4, "Validating Oracle Virtual Directory High Availability"
Oracle Directory Integration Platform: Section 8.6.4, "Validating Oracle Directory Services Manager High Availability"
Oracle Directory Services Manager: Section 8.6.4, "Validating Oracle Directory Services Manager High Availability"
Oracle Identity Federation: Section 8.13.3.6, "Validating Oracle Identity Federation High Availability"

8.7.3.2 Failures and Expected Behaviors

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

Oracle Internet Directory: Section 8.3.5, "Oracle Internet Directory Failover and Expected Behavior"
Oracle Virtual Directory: Section 8.4.5, "Oracle Virtual Directory Failover and Expected Behavior"
Oracle Directory Integration Platform: Section 8.5.4, "Oracle Directory Integration Platform Failover and Expected Behavior"
Oracle Directory Services Manager: Section 8.6.5, "Oracle Directory Services Manager Failover and Expected Behavior"
Oracle Identity Federation: Section 8.13.4, "Oracle Identity Federation Failover and Expected Behavior"

8.7.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 8.3.6, "Troubleshooting Oracle Internet Directory High Availability"
Oracle Virtual Directory: Section 8.4.6, "Troubleshooting Oracle Virtual Directory High Availability"
Oracle Directory Integration Platform: Section 8.5.5, "Troubleshooting Oracle Directory Integration Platform High Availability"
Oracle Directory Services Manager: Section 8.6.6, "Troubleshooting Oracle Directory Services Manager"
Oracle Identity Federation: Section 8.13.5, "Troubleshooting Oracle Identity Federation High Availability"

8.7.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 8.3.7, "Additional Oracle Internet Directory High Availability Issues"
Oracle Directory Services Manager: Section 8.6.7, "Additional Considerations for Oracle Directory Services Manager High Availability"

8.8 Oracle Access Manager High Availability

This section provides an introduction to Oracle Access Manager 11gR1 and describes how to design and deploy a high availability environment for Oracle Access Manager 11gR1.

Oracle Access Manager 11gR1 is the successor product to both Oracle Access Manager 10g (access only) and Oracle Single Sign-On 10g. Oracle Access Manager 11gR1 provides a single authoritative source for all authentication and authorization services. The core service provided is the checking of valid session tokens, the requesting of credentials if the session token is invalid or missing, and the issuing of session tokens, intercepting resource requests and evaluating access control policies to control access to resources. Oracle Access Manager 11gR1 features a pure Java server while continuing to use Oracle Single Sign-On 10g and Oracle Access Manager 10g agent components. The main new feature for 11gR1 for the agent is the Shared Secret Key Per WebGate (SSKPWG) feature.

Oracle Access Manager provides Single Sign-On features, thus preventing the user from re-logging in every time after authenticating once. It accomplishes this by managing the user session life cycle, which also involves facilitating global logout by orchestrating logout across all relying parties in the valid user session. Oracle Access Manager also ensures that resource access by users is authorized subject to the specified authorization policy.

Unlike Oracle Access Manager 10g, Oracle Access Manager 11gR1 no longer has any identity service and is a first class consumer of identity information from other identity management services such as native LDAP and Oracle Identity Manager.

Oracle Access Manager 11gR1 is an architecture evolution in the area of Access Management that delivers unified product architecture for enterprise and web Single Sign-On. Components of Oracle Access Manager leverage the Java EE middleware platform with a common underlying data model, shared underlying functionality, consistent semantics with a focus of interoperability and seamless integration. Oracle Access Manager 11gR1 offers co-existence and incremental migration paths for existing Single Sign-On deployments.

This section includes the following topics:

Section 8.8.1, "Oracle Access Manager Component Architecture"
Section 8.8.2, "Oracle Access Manager High Availability Concepts"
Section 8.8.3, "Oracle Access Manager High Availability Configuration Steps"

8.8.1 Oracle Access Manager Component Architecture

Figure 8-12 shows the Oracle Access Manager 11gR1 component architecture.

Figure 8-12 Oracle Access Manager Single Instance Architecture

Description of "Figure 8-12 Oracle Access Manager Single Instance Architecture"

Figure 8-12 shows the following components:

User agents: These include web browsers, Java applications, and Web services applications. The user agents access the Access Server and the administration and configuration tools using HTTP.
Protected resources: A protected resource is an application or web page to which access is restricted. Access to protected resources is controlled by WebGates or Custom Agents.
Administration and configuration tools: Oracle Access Manager can be administered and configured by the Oracle Access Manager console, the Oracle Enterprise Manager Fusion Middleware Control and the Oracle Enterprise Manager Grid Control, and the WebLogic Scripting Tool (WLST).
Access Server: The Access Server includes the Credential Collector, OSSO Proxy, and OAM Proxy components. The Coherence Distributed Object Cache is used to propagate configuration file changes between Access Servers

8.8.1.1 Oracle Access Manager Component Characteristics

An Oracle Access Manager 11gR1 deployment is composed of the following system entities:

Oracle Access Manager Agents - Oracle Access Manager agents are extensions of the Access Server that are responsible for ensuring that access is controlled as per the policies managed in the Access Server. Agents are the clients/programs (such as WebGate, Java Agents, custom Agents, and Oracle Single Sign-On Apache Modules) used by end-users to access various Web resources that are protected by Oracle Access Manager11gR1. The most commonly used user agents are web browsers. Oracle Access Manager 11gR1 is a Web Single Sign-On solution that is primarily focused on controlling resources accessible via HTTP (resources identified by a URL) and custom resource types.

Agents require the Access Server component to perform their functions. If the Access Server is unavailable, no access to protected servers will be permitted (users will be locked out of the system).

Oracle Access Manager 11gR1 agents connect to the Access Server over the front channel and back channel. The front channel communication takes place over HTTP(S) when the user needs to be authenticated. Front channel communications tend to be short-lived.

When an Oracle Access Manager agent communicates with the Access Server using the front channel HTTP binding, it will need to communicate through a load balancing router. This information is passed to the agent and configured as the Challenge Redirect URL in the authentication scheme.

Back channel communication takes place using a proprietary protocol called Oracle Access Protocol (OAP), which takes place over a TCP connection. Agents use back channel communications with the Access Server for every resource access request in order to make an authorization decision, thus these back-channel connections are persistent and long-lived.

When an Oracle Access Manager agent communicates with the Access Server using back channel OAP binding, it will be configured to use a primary / secondary model.

Oracle Access Manager agents are externally staged (deployed in the web tier) because this provides the best scalability.

WebGate caches information about resource requests and authentication schemes. The WebGate cache is flushed based on a configured timeout or a server-initiated cache purge.

WebGates refresh their configuration by polling the server every 60 seconds. When configuration changes are detected, they are persisted immediately. Existing connections are terminated and new connections are created in the event of a connection information change.

WebGate configuration includes information about the agent identity, agent credentials, agent-server security context, and connection parameters.
Protected Resources - These are the applications that are protected by Oracle Access Manager11gR1 (also referred to as partner applications). Access to these resources is subject to the access control policies in Oracle Access Manager 11gR1 and is enforced by Oracle Access Manager agents that are deployed in the access path of the protected resource (for example, Oracle Access Manager agents deployed in the Web Server, J2EE agents deployed in the Application Server). Agents are entities that control access to protected applications based on security policies. Agents present in the resource access path intercept every resource access request to enforce the security policy that protects the resources.
Access Server - This is the server side component that provides the core runtime access management services. It has an event-based design pattern that implements the core Oracle Access Manager services. An Access Server is a J2EE application that is packaged as an EAR file and is composed of Servlets and JSPs in addition to Java classes. It provides various Identity Provider (IDP) services. The Access Server in Oracle Access Manager 11gR1 provides Single Sign-On, Authentication, and Authorization services.
JMX Mbeans - Runtime Mbeans are packaged as part of the Access Server package. Config Mbeans are packaged as standalone WAR files.
WebLogic 11g SSPI providers are composed of Java classes that implement the SSPI interface along with the Access Java Access JDK. AccessGates are built using the pure Java Access JDK.
Administration Console - The Oracle Access Manager Administration Console is a J2EE application that hosts the Administration Console and provides services like Administration/Configuration to manage the Oracle Access Manager 11gR1 deployment. In Oracle Access Manager 11gR1, this component must be deployed to the WebLogic Administration Server.
WebLogic Scripting Tool (WLST) is composed of Java classes, which are included in the Access Server package. Limited administration of the Oracle Access Manager 11gR1 deployment is supported via the command line.
Fusion Middleware Control and Enterprise Manager Grid Control - Oracle Access Manager 11gR1 integrates with the Enterprise Manager Grid Control to display performance metrics and deployment topology.
Coherence Distributed Object Cache - Oracle Access Manager 11gR1 components rely on this infrastructure for real time change propagation.
External credential collectors are a set of JSPs.
The Oracle Access Manager Proxy is a customized version of the Apache MINA server (based on the JCA architecture), which includes MessageDrivenBeans and ResourceAdapters in addition to Java Server classes. It is included in the Access Server package.
The Oracle Single Sign-On (OSSO) Proxy is composed of Java classes, which are included in the Access Server package.
Data Repositories - Oracle Access Manager 11gR1 handles different types of information including Identity, Policy, Partner, Session and Transient data:
- LDAP for Identity data
- Files for Configuration and Partner data
- Coherence in-memory for Session and Transient Data
- Policy data will be stored in files or in an RDBMS
Oracle Access Manager 10g WebGates are C-based agents that are intended to be deployed in web servers.
Oracle Single Sign-On Apache modules are C-based agents that are intended to be deployed in Oracle HTTP Server web servers.
Oracle Access Manager 11g WebGates are C-based agents that are intended to be deployed in web servers.

8.8.1.1.1 Oracle Access Manager State Information

Authenticated user session information is persisted via the Coherence Distributed Object Cache. Use the Coherence Distributed Object Cache in-memory mode for Oracle Access Manager 11gR1.

Oracle Access Manager may create a transient state for unauthenticated users during the login processing. This state is generally not replicated among Oracle Access Manager nodes. To protect against effects of node failures during the login processing, the state may be optionally stored in an encrypted client cookie.

To store the transient state for unauthenticated users during login processing, change the Oracle Access Manager server parameter RequestCacheType from BASIC to COOKIE by following these steps:

Set up the environment for WLST by running this command:
```
DOMAIN_HOME/bin/setDomainEnv.sh
```

Start WLST by issuing this command:

Start WLST by issuing this command:
ORACLE_HOME/common/bin/wlst.sh

Connect to your domain:

wls:/IDM_Domain/serverConfig> connect()

Enter the WebLogic Administration username and password, and enter the URL for the Administration Server in the format:
```
t3://OAMHOST1.mycompany.com:7001
```

Issue this command:

wls:/IDM_Domain/serverConfig> configRequestCacheType(type="COOKIE")

Check that the command worked by issuing this command:

wls:/IDM_Domain/serverConfig> displayRequestCacheType()

Restart the Oracle Access Manager managed servers.

8.8.1.1.2 Oracle Access Manager Request Flow

The following list shows the steps in an Oracle Access Manager request flow:

The user tries to access a Oracle Access Manager 11gR1 protected Web Resource using his web browser.
The Oracle Access Manager agent^Foot 1 intercepts the request and tries to ascertain if the user has an authenticated session.
Since this is the user's first access, the user is redirected to the Oracle Access Manager 11gR1 Access Server for authentication.
Access Server's credential collector^Foot 2 component displays a Login Form.^Foot 3 The user submits his credentials to the Access Server.
Access Server validates the user's credentials and generates a security token. The user is redirected to the resource he tried to access in Step 1.
The Oracle Access Manager agent intercepts the request and extracts the security token (cookie).
The Oracle Access Manager agent then makes a back channel call^Foot 4 to the Access Server (OAP over TCP) to validate the session and authorize the request.
Oracle Access Manager authenticates the user from the LDAP repository.
Access server verifies the user's permissions against the configured policy for the web resource.
Access server responds to the WebGate request indicating that access is allowed.
The Oracle Access Manager agent allows the request to go through.^Foot 5
The user is now able to access the web resource he tried to access in Step 1.

8.8.1.1.3 Oracle Access Manager Process Lifecycle

As J2EE applications, the Access Server and Administration Console can be started using the user interface and command line tools provided by WebLogic Server.

The Access Server supports a health check request (a ping request over HTTP) that can be used by a load balancer for death detection.

Oracle Access Manager agents are native applications that reside in the protected application environment. No tools are provided as part of OAM 11gR1 but it is expected that environment specific tooling, where available, will be leveraged for the above purpose.

Oracle Access Manager 11gR1 is instrumented for server side metrics (using DMS) and this information is published to the Administration Console. Using DMS metrics collection, you can monitor the agent and server component metrics as a proxy for component monitoring. In addition, Oracle Access Manager 11gR1 supports fine-grained real time activity tracing, which can also serve as a proxy for component monitoring.

On startup, Access Server will initialize connections to the backend repositories. If the repository is not reachable, the Access Server will retry the connections to the repositories, using a timeout that grows exponentially with a configurable upper bound.

Access Server will provide continuity of service based on locally cached data if the backend connections go down. This will continue until the caches grow stale or the backend connections become alive again.

8.8.1.1.4 Oracle Access Manager Configuration Artifacts

The Oracle Access Manager configuration artifacts include these files:

DOMAIN_HOME/user_projects/domains/domainName/config/fmwconfig/oam-configuration.xml

The configuration file, which contains instance specific information.
DOMAIN_HOME/user_projects/domains/domainName/config/fmwconfig/oam-policy.xml
DOMAIN_HOME/user_projects/domains/domainName/config/fmwconfig/.oamkeystore

This is used for storing symmetric and asymmetric keys.
DOMAIN_HOME/user_projects/domains/domainName/config/fmwconfig/component_events.xml

Used for audit definition.
DOMAIN_HOME/user_projects/domains/domainName/config/fmwconfig/jazn-data.xml

Used for Administration Console permissions
DOMAIN_HOME/user_projects/domains/domainName/config/fmwconfig/servers/instanceName/logging.xml

Used for logging configuration.
DOMAIN_HOME/user_projects/domains/domainName/config/fmwconfig/servers/instanceName/dms_config.xml

Used for tracing logging.
DOMAIN_HOME/config/fmwconfig/cwallet.sso

Used for passwords

8.8.1.1.5 Oracle Access Manager External Dependencies

Oracle Access Manager has external runtime dependencies on the:

LDAP based Identity Store
- User Identity Repository
- LDAP access abstracted by User/Role API.
  
  Note:
  Oracle Access Manager always connects to one Identity store, which can be a physical server or a load balancer IP. If the primary is down, Oracle Access Manager reconnects and expects the load balancer to connect it to the secondary.
OCSP Responder Service
- Real-time X.509 Certification Validation
RDBMS Policy Store
- Policy (Authentication and Authorization) Repository
- RDBMS access abstracted by the OAM policy engine
Oracle Identity Manager (when OIM based password management is enabled)
- Oracle Identity Manager is used to provide Password Management Services and replaces the Oracle Access Manager 10g Identity Server
Oracle Identity Manager Policy Store (when Oracle Identity Manager-based password management is enabled)
- LDAP Repository containing Oblix Schema elements that are used to store Configuration, Metadata, and so on.
Oracle Adaptive Access Manager (when Oracle Adaptive Access Manager Advanced Authentication Scheme is selected)
Oracle Identity Federation (when Oracle Identity Federation Authentication Scheme is selected)

8.8.1.1.6 Oracle Access Manager Log File Location

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

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

8.8.2 Oracle Access Manager High Availability Concepts

This section provides conceptual information about using Oracle Access Manager in a high availability two-node cluster.

8.8.2.1 Oracle Access Manager High Availability Architecture

Figure 8-13 shows an Oracle Access Manager high availability architecture:

Figure 8-13 Oracle Access Manager High Availability Architecture

Description of "Figure 8-13 Oracle Access Manager High Availability Architecture"

In Figure 8-13, incoming authentication requests are received by the hardware load balancer, which routes them to WEBHOST1 or WEBHOST2 in the web tier. These hosts have Oracle HTTP Server installed. The Oracle HTTP Server then forwards requests on to the WebLogic managed servers using the WebLogic plugin mod_wl_ohs.

The load balancing router should use session stickiness for HTTP traffic only. OAP traffic does not use a load balancing router, so session stickiness is not required for OAP traffic.

Applications which are accessed by other Oracle HTTP Servers whose resources have restricted access must also have a WebGate, Oracle Single Sign-On Server agent (mod_osso agent), or custom agent configured. The WebGate on WEBHOST3 communicates with the Access Servers on OAMHOST1 and OAMHOST2 in the application tier using OAP. WEBHOST3 is an application web server, and for authentication, HTTP redirect is used to route requests to the load balancer and to WEBHOST1 and WEBHOST2. For a high availability deployment, you can optionally configure another host (for example, WEBHOST4) with the same components as WEBHOST3.

OAMHOST1 and OAMHOST2 deploy managed servers which host the Oracle Access Server application. These managed servers are configured in a cluster which allows the Access Servers to work in an active-active manner.

The WebLogic Administration Server runs on OAMHOST1 and deploys the WebLogic Administration Console, Oracle Enterprise Manager Fusion Middleware Control, and the Oracle Access Manager Console. The Administration Server can be configured to run in active-passive mode on OAMHOST2, which means that if OAMHOST1 becomes unavailable, then Administration Server can be manually started on OAMHOST2.

In the directory tier, the virtual IP ovd.mycompany.com is set up to route Oracle Virtual Directory requests to OVDHOST1 and OVDHOST2, which comprise an active-active Oracle Virtual Directory cluster. The virtual IP oid.mycompany.com is set up to route Oracle Internet Directory requests to OIDHOST1 and OIDHOST2, which comprise an active-active Oracle Internet Directory cluster.

An Oracle RAC database provides high availability in the data tier.

In Oracle Access Manager 11gR1, only one Oracle Access Manager cluster is supported per WebLogic Server domain. In addition, Oracle Access Manager clusters cannot span WebLogic Server domains.

A single instance Oracle Access Manager 11gR1 deployment satisfies the following high availability requirements:

Load handling
External connection management and monitoring
Recovery
Fault containment
Fault diagnostics
Administration Server offline

A multiple instance Oracle Access Manager 11gR1 deployment satisfies the following additional high availability requirements:

Redundancy
Client connection failover/continuity
Client load balancing
State management

Use of an external load balancing router is recommended for inbound HTTP connections. Outbound external connections to LDAP Servers (or OAM policy engine PDP/PIP) are load balanced with support for connection failover. Oracle Access Manager agents can load balance connections across multiple Access Servers.

Oracle Access Manager agents open persistent TCP connections to the Access Servers. This requires firewall connection timeouts to be sufficiently large to avoid premature termination of TCP connections.

The Access Server and Oracle Access Manager Administration Console interface with the OAM policy engine for policy evaluation and management. The OAM policy engine internally depends on a database as the policy repository. The database interactions are encapsulated within the OAM policy engine, with only the connectivity configuration information managed by Oracle Access Manager. The high availability characteristics of the interaction between Oracle Access Manager and the OAM policy engine are:

The database connection information is configured in the Oracle Access Manager configuration file synchronized among the Oracle Access Manager instances. Should the database connection information change at runtime, Access Server instances will re-initialize OES to complete the change activation.
Database communication is managed within the OAM policy engine, and generally decoupled from Oracle Access Manager and OAM policy engine interactions. The very first startup of an Oracle Access Manager server instance will fail, however, if the database is unreachable. An OAM policy engine bootstrap failure is treated as fatal by Oracle Access Manager, and the startup operation is aborted.
Transient database unavailability is transparently tolerated by OAM policy engine policy evaluation services, allowing Oracle Access Manager server runtimes to continue functioning uninterrupted. After the initial OAM policy engine bootstrap, the Oracle Access Manager instances may even be restarted while the database is unreachable -- the OAM policy engine will continue operating against its locally cached policies.
Oracle Access Manager policy management interfaces (in the Oracle Access Manager Administration Console and the CLI tool) will fail if the database is unreachable, as seen by the OAM policy engine management service interfaces. The operation may be retried at a later point in time, but no automated retry is provided for management operations.
Following a successful policy modification in the database repository, the OAM policy engine layer in the Oracle Access Manager server runtimes retrieves and activates the changes within a configurable OAM policy engine database poll interval (configured through Oracle Access Manager configuration). A positive acknowledgement of a policy change must be received from each Oracle Access Manager server runtime, otherwise the policy change cannot be considered successfully activated. The administrator can use the Oracle Access Manager Administration Console to remove any Oracle Access Manager instance with a policy activation failure from service.

8.8.2.1.1 Starting and Stopping the Cluster

In a high availability architecture, Oracle Access Manager 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 Access Manager 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 a high availability environment, a hardware load balancer is used to load balance requests between the multiple Oracle Access Manager instances. If one of the Oracle Access Manager instances fails, the load balancer detects the failure and routes requests to the surviving instances.

8.8.2.1.2 Cluster-Wide Configuration Changes

The standard Java EE artifacts that Oracle Access Manager uses are configured as part of the Oracle WebLogic domain in which Oracle Access Manager is installed. Oracle WebLogic Clusters provide automatic configuration synchronization for artifacts, such as data sources, across the WebLogic Server domain. At the same time, the WebLogic Server cluster synchronizes the deployments and libraries used by the Oracle Access Manager components.

Additionally, Oracle Access Manager application level configuration is stored in the Oracle Access Manager repository. Propagation of Oracle Access Manager configuration changes to all the cluster members is based on a distribution mechanism that leverages the Coherence Distributed Object Cache. All Oracle Access Manager components are notified of change events from the coherence layer, which are then taken up by the components. To ensure atomicity of the change, Oracle Access Manager components reload their entire configuration every time a change happens.

Oracle Access Manager configuration applies to all instances in a cluster. The only exceptions to the above (instance-specific configuration) supported in Oracle Access Manager 11gR1 are the Oracle Access Manager proxy host, Oracle Access Manager proxy port, and the instance-specific Coherence configuration (when Well Known Addresses (WKA) is used). The IP address of the proxy host and proxy port are stored in a configuration file. The Oracle Access Manager proxy port is the endpoint for OAP requests from agents. The IP address of the Coherence WKA is also stored in a configuration file. The Coherence WKA is used to determine the Coherence nodes that are authorized to receive Oracle Access Manager-specific traffic. The oam-configuration.xml file is the configuration file that stores this configuration information.

It is possible to configure clients of the Oracle Access Manager proxy to access the service using this virtual/logical IP.

The Oracle Access Manager proxy can be deployed (and its clients still able to access the service) when the logical IP and the component instance is migrated to any other physically different machine configured similarly.

Adding and removing Access Server instances is transparent to other Oracle Access Manager Access Server instances in the cluster. However, take care to ensure that the removal of a specific Access Server does not affect the load balancing and failover characteristics of the agents.

Restarting an Oracle Access Manager Access Server has no impact on any other running components or members of the cluster.

Online application redeployment does not cause any problems.

8.8.2.2 Protection from Failures and Expected Behaviors

This section describes how an Oracle Identity Management high availability cluster deployment protects components from failure. This section also describes expected behavior in the event of component failure.

The Identity Management Service Infrastructure system is protected from all process failures by the WebLogic Server infrastructure.

The following features protect the Oracle Access Manager high availability configuration from failure:

Session state is maintained in the Coherence Distributed Object Cache, which provides replication and failover for all session state information. Since Coherence is used in the in-memory mode, this information will not survive a simultaneous restart of all Oracle Access Manager components.
If an Access Server crashes, a WebGate with a persistent connection to that server waits for the connection to timeout, then it switches over to the secondary (backup) Access Server. Any outstanding requests are failed over to the secondary server.
Oracle Access Manager Access Servers support a heart beat check - a ping request over HTTP. In addition, the WebLogic Node Manager on the Managed Server can monitor the application and restart it if it is not running.
When a WebLogic Server node fails, external connection failover is based on the configuration and is based on the retry timeout as well as the number of retries. Oracle Access Manager Agent-Access Server failover is based on a timeout.
When the load balancing router or proxy server detects a WebLogic Server node failure, subsequent client connections are routed to the active instance, which picks up the session state from the Coherence Distributed Object Cache and carries on with the processing.
Back channel OAP bindings use a primary/secondary model for failover. Front Channel HTTP bindings use a load balancing router for failover.
When the lifetime of a connection expires, pending requests are allowed to complete before the connection is terminated. The connection object is returned to the pool.
When it receives an exception from another service, Oracle Access Manager will retry external connection requests. The number of retries is configurable, with an option for "no retries."

8.8.2.2.1 WebLogic Server Crash

When a user first requests access to a protected resource, the Oracle HTTP server establishes a connection with an Oracle Access Server and following initial user authentication, the Oracle Access Manager agent (for example, WebGate) places entries in a browser cookie for two access servers. From this moment, the client application will communicate directly with one of the access servers identified in the cookie. If that access server becomes unavailable, the application will communicate with the alternate access server identified in the cookie. If both servers become unavailable, the user will be asked to reauthenticate.

If a WLS_OAMx server crashes, Node Manager attempts to restart it locally.

Ongoing requests from the HTTP Server timeout and new requests are directed to the other WLS_OAMx server. Once the server's restart completes on the failed node, Oracle HTTP Server resumes routing any incoming requests to the server.

Note:

Oracle Access Manager servers also support a heartbeat check. This heartbeat is used to determine if the access server can service its requests. It checks things such as:

Whether the LDAP store can be accessed
Whether the policy store can be accessed

If the heartbeat succeeds, then the Access Server is capable of servicing requests, and requests will be sent to it. If the heartbeat fails, however, then requests will not be routed to the Access Server with the issue.

8.8.2.2.2 Node Failure

Node failures are treated in the same way as WebLogic Server crashes.

8.8.2.2.3 Database Failure

The Oracle Access Manager service Infrastructure is protected against failures in the database by using multi data sources. These multi data sources are typically configured during the initial set up of the system (Oracle Fusion Middleware Configuration Wizard allows you to define these multi-pools directly at installation time). They guarantee that when an Oracle RAC database instance fails, the connections are reestablished with available database instances. The multi data source allows you to configure connections to multiple instances in an Oracle RAC database.

For information about multi data source configuration with Oracle RAC and the MDS repository, see Section 4.1.2, "Using Multi Data Sources with Oracle RAC."

8.8.3 Oracle Access Manager High Availability Configuration Steps

This section provides high-level instructions for setting up a high availability deployment for Oracle Access Manager. This deployment includes two Oracle HTTP Servers, which distribute requests to two OAM servers. These OAM servers interact with an Oracle Real Application Clusters (Oracle RAC) database and optionally an external LDAP store. If any single component fails, then the remaining components will continue to function.

This section includes the following topics:

Section 8.8.3.1, "Prerequisites for Oracle Access Manager Configuration"
Section 8.8.3.2, "Run the Repository Creation Utility to Create the OAM Schemas in a Database"
Section 8.8.3.3, "Installing Oracle WebLogic Server"
Section 8.8.3.4, "Install and Configure the Oracle Access Manager Application Tier"
Section 8.8.3.5, "Creating boot.properties for the Administration Server on OAMHOST1"
Section 8.8.3.6, "Start OAMHOST1"
Section 8.8.3.7, "Validating OAMHOST1"
Section 8.8.3.8, "Configure OAM on OAMHOST2"
Section 8.8.3.9, "Start OAMHOST2"
Section 8.8.3.10, "Validating OAMHOST2"
Section 8.8.3.11, "Change Request Cache Type"
Section 8.8.3.12, "Configure Oracle Access Manager to Work with Oracle HTTP Server"
Section 8.8.3.13, "Configure Oracle Access Manager to use an External LDAP Store"
Section 8.8.3.14, "Validating the Oracle Access Manager Configuration"
Section 8.8.3.15, "Configuring Oracle Coherence to Keep Configuration Files in Sync"
Section 8.8.3.16, "Scaling Up and Scaling Out the Oracle Access Manager Topology"

8.8.3.1 Prerequisites for Oracle Access Manager Configuration

Before you configuring Oracle Access Manager for high availability, you must:

Run the Repository Creation Utility to create the OAM schemas in a database.

See Section 8.8.3.2, "Run the Repository Creation Utility to Create the OAM Schemas in a Database" for instructions on running the Repository Creation Utility to create the OAM schemas.
Install Oracle WebLogic Server on OAMHOST1 and OAMHOST2.

Follow the steps in Section 8.8.3.3, "Installing Oracle WebLogic Server" to install Oracle WebLogic Server on OAMHOST1 and OAMHOST2.
Install the Oracle Identity Management executables on OAMHOST1 and OAMHOST2.

Follow the steps in Section 8.8.3.4, "Install and Configure the Oracle Access Manager Application Tier" to install the Oracle Identity Management executables on OAMHOST1 and OAMHOST2.
Make sure that a highly available LDAP implementation is available. For information about installing and configuring Oracle Internet Directory, see Section 8.3.3, "Oracle Internet Directory High Availability Configuration Steps." For information about installing and configuring Oracle Virtual Directory, see Section 8.4.3, "Oracle Virtual Directory High Availability Configuration Steps."

8.8.3.2 Run the Repository Creation Utility to Create the OAM Schemas in a Database

See Section 8.2.4.1, "Executing the Repository Creation Utility" for instructions on running the Repository Creation Utility to create the OAM schemas in your database repository.

8.8.3.3 Installing Oracle WebLogic Server

Prior to installing the Oracle WebLogic Server, ensure that your machines meet the system, patch, kernel, and other requirements as specified in Oracle Fusion Middleware Installation Guide for Oracle WebLogic Server.

Start the installer, then proceed as follows:

On the Welcome screen, click Next.
On the Choose Middleware Home Directory screen, select Create a New Middleware Home.

For Middleware Home Directory, enter:

ORACLE_BASE/product/fmw

Note:
ORACLE_BASE is the base directory under which Oracle products are installed. The recommended value is /u01/app/oracle.

Click Next.
On the Register for Security Updates screen, enter your contact information so that you can be notified of security updates.

Click Next.
On the Choose Install Type screen, select Custom.

Click Next.
On the Choose Products and Components screen, select only Oracle JRockit SDK, and click Next.
On the Choose Product Installation Directories screen, accept the directory ORACLE_BASE/product/fmw/wlserver_10.3.

Click Next.
On the Installation Summary screen, click Next.
On the Installation Complete screen, deselect Run Quickstart.

Click Done.

8.8.3.4 Install and Configure the Oracle Access Manager Application Tier

This section describes how to install Oracle Fusion Middleware components on OAMHOST1 and OAMHOST2.

8.8.3.4.1 Install Oracle Fusion Middleware for Identity Management

This section includes the steps for installing the Oracle Identity Management software into the previously created Middleware Home directory. The steps should be performed on OAMHOST1 and OAMHOST2.

Start the installer for Oracle Fusion Middleware as follows:

OAMHOST1> runInstaller

When the installer prompts you for a JRE/JDK location, enter the Oracle SDK location created in the Oracle WebLogic Server installation, for example, ORACLE_BASE/product/fmw/jrockit_160_14_R27.6.5-32.

Then proceed as follows:

On the Welcome screen, click Next.
On the Prerequisite Checks screen, verify that the checks complete successfully, then click Next.
On the Specify Installation Location screen, enter the following values:
- Oracle Middleware Home: Select the previously installed Middleware home from the list for MW_HOME, for example:
```
/u01/app/oracle/product/fmw
```
- Oracle Home Directory: Enter idm.
Click Next.
On the Installation Summary screen, click Install.

When prompted, on Linux and UNIX installations, execute the script oracleRoot.sh as the root user.
On the Installation Complete screen, click Finish.

8.8.3.4.2 Configure Oracle Identity Management on OAMHOST1

This section creates the Oracle Identity Management domain on OAMHOST1.

Start the configuration wizard by executing the command:

MW_HOME/oracle_common/common/bin/config.sh

Then proceed as follows:

In the Welcome screen, select Create a New WebLogic Domain, and then click Next.
In the Select Domain Source Screen:

Select Generate a domain configured automatically to support the following products:

And select the following products:
- Oracle Enterprise Manager
- Oracle JRF (selected by default)
- Oracle Access Manager with Database Policy Store
Click Next.
In the Specify Domain and Location screen enter:
- Domain name: IDM_Domain
- Domain Location: Accept the default.
- Application Directory: Accept the default.
Click Next.
In the Configure Administrator Username and Password screen, enter the username and password to be used for the domain's administrator, and click Next.
In the Configure Server Start Mode and JDK screen, make the following selections:
- WebLogic Domain Startup Mode: Select Production Mode.
- JDK Selection: Select JROCKIT SDK1.6.0_17 SDK.
In the Configure JDBC Component Schema screen, select all of the data sources, then select Configure selected data sources as RAC multi data sources.

Click Next.
In the Configure RAC Multi Data Source Component Schema screen, select the first data source, OAM Admin Server, and enter the following:
- Data source: OAM
- Service Name: oam.mycompany.com
- User Name: OAM_OAM (assuming OAM was used as the RCU prefix)
- Password: The password for above account
In the top right box, click Add to add an Oracle RAC host. Enter the following information:
- Host Name: OAMDBHOST1
- Instance Name: oamdb1
- Port: 1521
Click Add again to add the second database host and enter the following information:
- Host Name: OAMDBHOST2
- Instance Name: oamdb2
- Port: 1521
Click Next.
In the Test Component Schema screen, the configuration wizard attempts to validate the data source.

If the data source validation succeeds, click Next.

If it fails, click Previous, correct the issue, and try again.
In the Select Optional Configuration screen, select:
- Administration Server
- Managed Server Clusters and Machines
Click Next.
In the Customize Server and Cluster Configuration screen, select Yes, and click Next.
In the Configure the Administration Server screen, enter the following values:
- Name: AdminServer
- Listen Address: OAMHOST1.mycompany.com
- Listen Port: 7001
- SSL listen port: Not applicable
- SSL enabled: leave unchecked
Click Next.
On the Configure Managed Servers screen, create an entry for each OAMHOST in the topology, that is, one for the OAM Server running on OAMHOST1 and one for the OAM Server running on OAMHOST2.

Select the OAM_SERVER entry and change the entry to the following values:
- Name: WLS_OAM1
- Listen Address: OAMHOST1.mycompany.com
- Listen Port: 14100
For the second OAM_SERVER, click Add and supply the following information:
- Name: WLS_OAM2
- Listen Address: OAMHOST2.mycompany.com
- Listen Port: 14100
Click Next.
In the Configure Clusters screen, create a cluster by clicking Add.

Enter name: OAM_Cluster

Leave all other fields at the default settings.

Click Next.
On the Assign Servers to Clusters screen, associate the managed servers with the cluster, as follows:
- Click the cluster name OAM_Cluster in the right window.
- Click the managed server WLS_OAM1, then click the arrow to assign it to the cluster.
- Repeat for managed server WLS_OAM2.
Click Next.
On the Configure Machines screen, create a machine for each host in the topology. Click the UNIX tab if your hosts use a UNIX-based operating system. Otherwise, click the Machines tab. Supply the following information:
- Name: Name of the host. The best practice is to use the DNS name (OAMHOST1)
- Node Manager Listen Address: The DNS name of the machine (OAMHOST1.mycompany.com)
- Node Manager Port: A port for Node Manager to use.
Repeat the steps for OAMHOST2:
- Name: Name of the host. The best practice is to use the DNS name (OAMHOST2)
- Node Manager Listen Address: The DNS name of the machine (OAMHOST2.mycompany.com)
- Node Manager Port: A port for Node Manager to use.
Click Next.
In the Assign Servers to Machines screen, indicate which managed servers will run on the machines just created.
- Click the machine OAMHOST1 in the right window.
- Click the managed server WLS_OAM1 in the left window.
- Click the arrow to assign the managed server to the host OAMHOST1.
- Click the machine OAMHOST2 in the right window.
- Click the managed server WLS_OAM2 in the left window.
- Click the arrow to assign the managed server to the host OAMHOST2.
Click Next.
On the Configuration Summary screen, click Create to begin the creation process.

When prompted, on Linux and UNIX installations, execute the script oracleRoot.sh as the root user.

8.8.3.5 Creating boot.properties for the Administration Server on OAMHOST1

This section describes how to create a boot.properties file for the Administration Server on OAMHOST1. 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 OAMHOST1, 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 OAMHOST1 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://oamhost1.mycompany.com:7001/console
```
- Oracle Enterprise Manager Fusion Middleware Control at:
```
http://oamhost1.mycompany.com:7001/em
```
Log into these consoles using the weblogic user credentials.

8.8.3.6 Start OAMHOST1

Now you will start OAMHOST1.

This section describes the steps for starting OAMHOST1.

8.8.3.6.1 Create the Node Manager Properties File on OAMHOST1

Before you can start managed servers from the console, you must create a Node Manager property file. You do this by running the script setNMProps.sh, which is located in the MW_HOME/oracle_common/common/bin directory. For example:

OAMHOST1> $MW_HOME/oracle_common/common/bin/setNMProps.sh

8.8.3.6.2 Start Node Manager

Start Node Manager by issuing the following command:

OAMHOST1> $MW_HOME/wlserver_10.3/server/bin/startNodeManager.sh

8.8.3.6.3 Start Oracle Access Manager on OAMHOST1

To start Oracle Access Manager on OAMHOST1, follow these steps:

Log into the WebLogic Administration Console using this URL:
```
http://oamhost1.mycompany.com:7001/console
```
Supply the WebLogic administrator username and password.
Select Environment - Servers from the Domain Structure menu.
Click the Control tab.
Click the server WLS_OAM1.
Click Start.
Click OK to confirm that you want to start the server.

8.8.3.7 Validating OAMHOST1

Validate the implementation by connecting to the OAM Console at the following URL:

http://OAMHOST1.mycompany.com:14100/oamconsole

The implementation is valid if the OAM Admin console login page is displayed and you can login using the WebLogic administrator account.

8.8.3.8 Configure OAM on OAMHOST2

Once the configuration has succeeded on OAMHOST1, you can propagate it to OAMHOST2. You do this by packing the domain using the pack script on OAMHOST1, and unpacking the domain using the unpack script on OAMHOST2.

Both scripts reside in the MW_HOME/oracle_common/common/bin directory.

On OAMHOST1, enter:

pack.sh -domain=$MW_HOME/user_projects/domains/IDM_Domain \
    -template=/tmp/idm_domain.jar -template_name="OAM Domain" -managed=true

This creates a file called idm_domain.jar in the /tmp directory. Copy this file to OAMHOST2.

On OAMHOST2, enter:

unpack.sh -domain=$MW_HOME/user_projects/domains/IDM_Domain \
    -template=/tmp/idm_domain.jar

8.8.3.9 Start OAMHOST2

Now you will start OAMHOST2.

This section describes the steps for starting OAMHOST2.

8.8.3.9.1 Create the Node Manager Properties File on OAMHOST2

OAMHOST1> $MW_HOME/oracle_common/common/bin/setNMProps.sh

8.8.3.9.2 Start Node Manager

Start Node Manager by issuing the following command:

OAMHOST2> $MW_HOME/wlserver_10.3/server/bin/startNodeManager.sh

8.8.3.9.3 Start Oracle Access Manager on OAMHOST2

To start Oracle Access Manager on OAMHOST2, follow these steps:

Log into the WebLogic Administration Console using this URL:
```
http://oamhost2.mycompany.com:7001/console
```
Supply the WebLogic administrator username and password.
Select Environment - Servers from the Domain Structure menu.
Click the Control tab.
Click the server WLS_OAM2.
Click Start.
Click OK to confirm that you want to start the server.

8.8.3.10 Validating OAMHOST2

Validate the implementation by connecting to the OAM server using the following URL:

http://OAMHOST2.mycompany.com:14100/oam

The implementation is valid if the OAM login page is displayed. Note at this point it will show an "Action failed" error on the page. This is normal because you are accessing the page directly rather than as a login request.

8.8.3.11 Change Request Cache Type

In high availability configurations, the Request Cache type needs to be changed from BASIC to COOKIE.

This is done using WLST:

Set up the environment for WLST by running this command:
```
DOMAIN_HOME/bin/setDomainEnv.sh
```
Start WLST by issuing this command:
```
ORACLE_HOME/common/bin/wlst.sh
```
Connect to your domain:
```
wls:/IDM_Domain/serverConfig> connect()
```
Enter the WebLogic Administration username and password, and enter the URL for the Administration Server in the format:
```
t3://OAMHOST1.mycompany.com:7001
```

Issue this command:

wls:/IDM_Domain/serverConfig> configRequestCacheType(type="COOKIE")

Check that the command worked by issuing this command:

wls:/IDM_Domain/serverConfig> displayRequestCacheType()

Restart the WLS_OAM1 and WLS_OAM2 managed servers.

8.8.3.12 Configure Oracle Access Manager to Work with Oracle HTTP Server

This section provides steps for configuring Oracle Access Manager to work with the Oracle HTTP Server.

8.8.3.12.1 Update Oracle HTTP Server Configuration

On WEBHOST1 and WEBHOST2, create a file named oam.conf in the following directory:

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

Create the file with the following lines:

NameVirtualHost *:7777
<VirtualHost *:7777>
 
    ServerName sso.mycompany.com:7777
    ServerAdmin you@your.address
    RewriteEngine On
    RewriteOptions inherit

    <Location /oam>
        SetHandler weblogic-handler
        WebLogicCluster oamhost1.mycompany.com:14100,oamhost2.mycompany.com:14100
    </Location>

</VirtualHost>

8.8.3.12.2 Restart Oracle HTTP Server

Restart the Oracle HTTP Server on WEBHOST1 and WEBHOST2:

WEBHOST1>opmnctl stopall
WEBHOST1>opmnctl startall

WEBHOST2>opmnctl stopall
WEBHOST2>opmnctl startall

8.8.3.12.3 Make Oracle Access Manager Server Aware of the Load Balancer

By default, Oracle Access Manager will send requests to the login page located on the local server. In a high availability deployment, this needs to be changed so that login page requests are sent to the load balancer.

Follow these steps:

Log into the Oracle Access Manager Console at this URL as the oamadmin user:
```
http://oamhost1.mycompany.com:7001/oamconsole
```
Click on the System Configuration tab.
Double-click on Server Instances.
Click on the SSO Engine tab.
Enter the following information:
- OAM Server Host: sso.mycompany.com
- OAM Server Port: 7777
- OAM Server Protocol: https
Click Apply.
Restart managed servers WLS_OAM1 and WLS_OAM2.

8.8.3.13 Configure Oracle Access Manager to use an External LDAP Store

By default, Oracle Access Manager uses its own in built-in LDAP server. In a highly available configuration, it is recommended that an external LDAP directory be used as the directory store. This section describes how to set up an external LDAP store.

Note:

It is recommended that you back up the environment and LDAP store before performing any of the subsequent steps in this section.

8.8.3.13.1 Create Users and Groups in LDAP

Prior to performing this step, ensure that there is a group in your LDAP store for Oracle Access Manager administrators, such as OAMAdministrator, and that a user such as oamadmin exists in that group.

Follow these steps:

Create the following files:

oam_user.ldif, with this text:

dn: cn=oamadmin,cn=Users,dc=mycompany,dc=com
cn: oamadmin
sn: oamadmin
description: oamadmin
uid: oamadmin
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetorgperson
objectclass: orcluser
objectclass: orcluserV2
userpassword: mypasswd

oam_group.ldif, with this text:

dn: cn=OAMAdministrator,cn=Groups,dc=us,dc=mycompany,dc=com
cn: OAMAdministrator
displayname: OAMAdministrator
description: OAMAdministrator
uniquemember: cn=oamadmin,cn=Users,dc=us,dc=mycompany,dc=com
objectclass: top
objectclass: groupofuniquenames
objectclass: orclgroup

Load the user and group into LDAP using the following commands:

ldapadd -h myoid.mycompany.com -p 389 -D cn="orcladmin" -w mypasswd -c -v -f oam_user.ldif

ldapadd -h myoid.mycompany.com -p 389 -D cn="orcladmin" -w mypasswd -c -v -f oam_group.ldif

Note:

These steps must be performed from the LDAP server.

8.8.3.13.2 Create a User Identity Store

To create a user identity store, follow these steps:

Go to the Oracle Access Manager Console at the URL:
```
http://oamhost1.mycompany.com:7001/oamconsole
```
Log in using the WebLogic administration user.
Click Add Identity Store and enter the following information:
- Name: LDAP_DIR
- LDAP Provider: Select the type of external LDAP store. For example: Oracle Virtual Directory or Oracle Internet Directory
- LDAP URL: Enter the URL of the external LDAP store. For example: ldap://ovd.mycompany.com:389
- Principal: Enter the principal of the LDAP store. For example: cn=orcladmin
- Credential: Enter the password of the principal.
- User Search Base: Enter the location of users in the LDAP store. For example, cn=Users,dc=mycompany,dc=com
- Group Search Base: Enter the location of groups in the LDAP store. For example, cn=Groups,dc=mycompany,dc=com
- User Name Attribute: For example: uid
- OAM Administrator Role: OAMAdministrator
Click Apply.
Click Test Connection to validate the connection to the LDAP server.

8.8.3.13.3 Set LDAP to Primary Authentication Store

Now that you defined the LDAP identity store, you must set it as the primary authentication store. To do this, follow these steps in the Oracle Access Manager Console:

Click the System Configuration tab.
Select Data Sources - User Identity Stores from the navigation pane.
Click LDAP_DIR.
Select Open from the Actions menu.
Click Set as Primary.
Test the connection by clicking Test Connection.
Restart the servers Admin Server, WLS_OAM1, and WLS_OAM2.

8.8.3.14 Validating the Oracle Access Manager Configuration

Validate the configuration by logging into the Oracle Access Manager Console at http://oamhost1.mycompany.com:7001/oamconsole as oamadmin.

8.8.3.15 Configuring Oracle Coherence to Keep Configuration Files in Sync

In a highly available environment Oracle uses Oracle Coherence to keep configuration files in sync. Oracle Coherence uses port 9095 by default, but this can be changed through the Oracle Access Manager Console.

Click on the System Configuration tab.
Expand Servers in the navigator.
Double-click on the Managed Server whose port you wish to change.
Click on the Coherence tab.
Change the value of Local Port to the desired value.
Click Apply.
Restart the Administration Server and all the managed servers residing in the same cluster as the managed server that has been updated.

8.8.3.16 Scaling Up and Scaling Out the Oracle Access Manager Topology

This section describes how to scale up and scale out an Oracle Access Manager high availability topology. Perform a scale up operation to add a new Oracle Access Manager managed server instance is added to a node already running one or more server instances. Perform a scale out operation to add a new Oracle Access Manager managed server instance to a new node.

8.8.3.16.1 Scaling Up Oracle Access Manager

Scale up OAM as follows:

From the Domain Structure window of the Oracle WebLogic Server Administration Console, expand the Environment node and then Servers. The Summary of Servers page appears.
In the Change Center, click Lock & Edit.
Select an existing server on the host you wish to extend, for example: WLS_OAM1.
Click Clone.
Enter the following information:
- Server Name: A new name for the server, for example: WLS_OAM3.
- Server Listen Address: The name of the host on which the managed server will run.
- Server Listen Port: The port the new managed server will use, this port must be unique within the host.
Click OK.
Click on the newly created server WLS_OAM3
Set the SSL listen port. This should be unique on the host that the managed server will be running on.
Click Save.
Disable host name verification for the new managed server. Before starting and verifying the WLS_OAM3 managed server, you must disable host name verification. You can re-enable it after you have configured server certificates for the communication between the Oracle WebLogic Administration Server and the Node Manager in OAMHOSTn.

If the source server from which the new one was cloned had already disabled hostname verification, these steps are not required, as the hostname verification settings were propagated to the cloned server. To disable host name verification:
1. In Oracle Enterprise Manager Fusion Middleware Control, select Oracle WebLogic Server Administration Console.
2. Expand the Environment node in the Domain Structure window.
3. Click Servers. The Summary of Servers page appears.
4. Select WLS_OAM3 in the Names column of the table. The Settings page for server appears.
5. Click the SSL tab.
6. Click Advanced.
7. Set Hostname Verification to None.
8. Click Save.
Click Activate configuration from the Change Center menu.

Register the new managed server with OAM. You now need to configure the new managed server now as an OAM server. You do this from the Oracle OAM console. Proceed as follows:

Log in to the OAM console at http://oamhost1.mycompany.com:7001/oamconsole as the oamadmin user.
Click the System Configuration tab.
Click Server Instances.
Select Create from the Actions menu.
Enter the following information:
- Server Name: WLS_OAM3
- Host: Host that the server will run on
- Port: Listen port that was assigned when the managed server was created
- OAM Proxy Port: Port you want the OAM proxy to run on. This is unique for the host
- Proxy Server ID: AccessServerConfigProxy
- Mode: Open
Click Coherence tab.

Set Local Port to a unique value on the host.

Click Apply.
Click Apply.

You can now start the Access server. In order for the Access server to be used, you must inform any Webgates of its existence. You do that as follows:

Log in to the OAM console at http://oamhost1.mycompany.com:7001/oamconsole as the oamadmin user.
Click the System Configuration tab.
Expand Agents -> OAM Agents -> 10g Agents (for 10g WebGates) or Agents > OAM Agents > 11g Agents (for 11g WebGates).
Double click the Webgate you want to change.
Add the new server to either the primary or secondary server list by clicking the Add + icon.
Select the server name from the list.
Click Apply

8.8.3.16.2 Scaling Out Oracle Access Manager

Scale out is very similar to scale up, but first requires the software to be installed on the new node.

Install Oracle WebLogic Server on the new host as described in Section 8.8.3.3, "Installing Oracle WebLogic Server."
Install Oracle Fusion Middleware Identity Management components on the new host as described in Section 8.8.3.4, "Install and Configure the Oracle Access Manager Application Tier."
Log in to the Oracle WebLogic Server Administration Console at http://oamhost1.mycompany.com:7001/oamconsole.
From the Domain Structure window of the Oracle WebLogic Server Administration Console, expand the Environment node and then Servers. The Summary of Servers page appears.
In the Change Center, click Lock & Edit.
Select an existing server on the host you want to extend, for example: WLS_OAM1.
Click Clone.
Enter the following information:
- Server Name: A new name for the server, for example: WLS_OAM3.
- Server Listen Address: The name of the host on which the managed server will run.
- Server Listen Port: The port the new managed server will use. This port must be unique within the host.
Click OK.
Click the newly created server WLS_OAM3.
Set the SSL listen port. This should be unique on the host that the managed server will run on.
Click Save.
Disable host name verification for the new managed server. Before starting and verifying the WLS_OAM3 managed server, you must disable host name verification. You can re-enable it after you have configured server certificates for the communication between the Oracle WebLogic Administration Server and the Node Manager in OAMHOSTn.

If the source server from which the new one was cloned had already disabled hostname verification, these steps are not required, as the hostname verification settings was propagated to the cloned server. To disable host name verification, proceed as follows:
1. In Oracle Enterprise Manager Fusion Middleware Control, select Oracle WebLogic Server Administration Console.
2. Expand the Environment node in the Domain Structure pane.
3. Click Servers. The Summary of Servers page appears.
4. Select WLS_OAM3 in the Names column of the table. The Settings page for server appears.
5. Click the SSL tab.
6. Click Advanced.
7. Set Hostname Verification to None.
8. Click Save.
Click Activate Configuration from the Change Center menu.

Pack the domain on OAMHOST1 using the command:

pack.sh -domain=ORACLE_BASE/admin/IDM_Domain/aserver/IDM_Domain -template =/tmp/idm_domain.jar -template_name="OAM Domain" -managed=true

The pack.sh script is located in MW_HOME/oracle_common/common/bin.

Unpack the domain on the new host using the command:

unpack.sh -domain=ORACLE_BASE/admin/IDM_Domain/mserver/IDM_Domain -template=/tmp/idm_domain.jar -template_name="OAM Domain" -app_dir=ORACLE_BASE/admin/IDM_Domain/mserver/applications

The unpack.sh script is located in MW_HOME/oracle_common/common/bin.

Before you can start managed servers from the console, you must create a node manager properties file on OAMHOST3. You do this by running the script setNMProps.sh, which is located in MW_HOME/oracle_common/common/bin. Type:
```
MW_HOME/oracle_common/common/bin/setNMProps.sh
```

Register the new managed server with OAM. The new managed server now needs to be configured as an OAM server. You do this from the Oracle OAM console, as follows:

Log in to the OAM console at http://oamhost1.mycompany.com:7001/oamconsole as the oamadmin user.
Click the System Configuration tab.
Click Server Instances.
Select Create from the Actions menu.
Enter the following information:
- Server Name: WLS_OAM3
- Host: Host that the server will be running on, OAMHOST3.
- Port: Listen port that was assigned when the managed server was created.
- OAM Proxy Port: Port you want the OAM proxy to run on. This is unique for the host.
- Proxy Server ID: AccessServerConfigProxy
- Mode: Open
Click Apply.

You can now start the Access Server. In order for the server to be used, however, you must inform any Webgates of its existence. You do that as follows:

Log in to the OAM console at http://oamhost1.mycompany.com:7001/oamconsole as the oamadmin user.
Click the System Configuration tab.
Expand Agents -> OAM Agents ->10g Agents.
Double click the Webgate you want to change.
Add the new server to either the primary or secondary server list by clicking the Add [+] icon.
Select the server name from the list.
Click Apply.

Update the Web Tier. Now that the new managed server has been created and started, the web tier will start to direct requests to it. Best practice, however, is to inform the web server that the new managed server has been created.

You do this by updating the file OAM.conf on each of the web tiers. This file resides in the directory: ORACLE_INSTANCE/config/OHS/component name/moduleconf.

Add the new server to the WebLogicCluster directive in the file, for example, change:

<Location /OAM_admin>
    SetHandler weblogic-handler
    WebLogicCluster
 OAMhost1.mycompany.com:14200,OAMhost2.mycompany.com:14200
</Location>

to:

<Location /OAM_admin>
    SetHandler weblogic-handler
    WebLogicCluster
 OAMhost1.mycompany.com:14200,OAMhost2.mycompany.com:14200,OAMhsot3.mycompany.com:14300
</Location>

8.9 Oracle Identity Manager High Availability

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

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

Automating user identity provisioning can reduce Information Technology (IT) administration costs and improve security. Provisioning also plays an important role in regulatory compliance. Key features of Oracle Identity Manager include password management, workflow and policy management, identity reconciliation, reporting and auditing, and extensibility through adapters.

Oracle Identity Manager provides the following key functionalities:

User Administration
Workflow and Policy
Password Management
Audit and Compliance Management
User Provisioning
Organization and Role Management

For details about Oracle Identity Manager, see the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

This section includes the following topics:

Section 8.9.1, "Oracle Identity Manager Component Architecture"
Section 8.9.2, "Oracle Identity Manager High Availability Concepts"
Section 8.9.3, "Oracle Identity Manager High Availability Configuration Steps"

8.9.1 Oracle Identity Manager Component Architecture

Figure 8-14 shows the Oracle Identity Manager architecture:

Figure 8-14 Oracle Identity Manager Component Architecture

Description of "Figure 8-14 Oracle Identity Manager Component Architecture"

8.9.1.1 Oracle Identity Manager Component Characteristics

Oracle Identity Manager Server is Oracle's self-contained, standalone identity management solution, based on Java EE standards. It provides User Administration, Workflow and Policy, Password Management, Audit and Compliance Management, User Provisioning and Organization and Role Management functionalities.

Oracle Identity Manager is a standard Java EE application that is deployed on Oracle WebLogic Sever and uses a database to store runtime and configuration data. The MDS schema contains configuration information; the runtime and user information is stored in the OIM schema.

Oracle Identity Manager connects to the SOA managed servers over RMI to invoke the SOA EJBs.

Oracle Identity Manager uses the human workflow module of the Oracle SOA Suite for managing its request workflow. Oracle Identity Manager connects to SOA using SOA Soapurl for connecting to SOA webservices. This is the front end URL for SOA; this should be the load balancer or webserver URL in case of clustered SOA servers. When the workflow is completed, SOA calls back Oracle Identity Manager webservices using OIMFrontEndURL. Oracle SOA is deployed along with the Oracle Identity Manager.

Several Oracle Identity Manager modules use JMS queues. Each queue is processed by a separate Message Driven Bean (MDB), which is also part of the Oracle Identity Manager application. Message producers are also part of the Oracle Identity Manager application.

Oracle Identity Manager uses embedded Oracle Entitlement Server (microkernel), which is also part of the Oracle Identity Manager engine. Oracle Entitlement Server (OES) is used for authorization checks inside Oracle Identity Manager. For example, one of the policy constraints determines that only users with certain roles are allowed create users. This is defined using the Oracle Identity Manager user interface.

Oracle Identity Manager uses a Quartz based scheduler for scheduled activities. There are various scheduled activities that happen in the background. For example, one of the scheduled tasks is to disable users after the end date of the users.

Oracle Identity Manager simply links to Oracle BI Publisher for all the reporting features. BI Publisher is expected to be in a different domain or same domain, so the integration is only a simple static URL integration. There is no interaction between BI Publisher and Oracle Identity Manager runtime components. BI Publisher is configured to use the same OIM database schema for reporting purposes.

When the LDAPSync module in Oracle Identity Manager is enabled, Oracle Identity Manager connects with external directory servers through Oracle Virtual Directory.

8.9.1.2 Runtime Processes

Oracle Identity Manager is a Java EE application that is deployed on Oracle WebLogic Server as a no stage application. The Oracle Identity Manager server is initialized when the WebLogic Server it is deployed on starts up. As part of the application initialization, the quartz based scheduler is also started. Once initialization is done, the system is ready to receive requests from clients.

Remote Manager and Design Console need to be started as standalone utilities separately.

8.9.1.3 Component and Process Lifecycle

Oracle Identity Manager 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 Manager application.

Oracle Identity Manager is a standard Java EE application, and it starts up after the application server components have been started up. Also Oracle Identity Manager uses the authenticator which is part of the Oracle Identity Manager component mechanism; it starts up before the WebLogic JNDI are initialized and the application is started. This is loaded from the OIM ORACLE_HOME.

Oracle Identity Manager uses a Quartz technology-based scheduler. Quartz starts the scheduler thread on all the WebLogic Server instances. It uses the database as the centralized storage for picking and executing the scheduled activities. If one of the scheduler instances picks up a job, the other instances will not pick up that same job.

Oracle Identity Manager caches certain system configuration values in the cache in memory of the server instance from the database. These caches are independently loaded and not shared among the servers. Any changes to the system configuration triggers the cache cleanup; this process notifies all the servers in the cluster. Oracle Identity Manager uses oscache, jgroups for this purpose. Jgroups uses multicast addresses. A valid multicast address is randomly generated during installation and seeded to the Oracle Identity Manager metadata repository file.

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 to modify the configuration of the application.

8.9.1.4 Starting and Stopping Oracle Identity Manager

Oracle Identity Manager lifecycle events can be managed using one or more of the following command line tools and consoles:

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

8.9.1.5 Configuration Artifacts

The configuration for the Oracle Identity Manager server is stored in the MDS repository and is managed using MBeans. The oim-config.xml file is the main configuration file. The OIM configuration can be managed using the MBean browser through the Oracle Enterprise Manager Fusion Middleware Control or through the command line MDS utilities. The oim-config.xml file is stored in the /db/oim-config.xml location of the MDS Repository.

For more information about the MDS utilities, see the MDS utilities section of Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager.

JMS is configured out of the box by the installer. All the necessary JMS queues, connection pools, data sources and so on are configured on the WebLogic application servers. The following queues are created when Oracle Identity Manager is deployed:

oimAttestationQueue
oimAuditQueue
oimDefaultQueue
oimKernelQueue
oimProcessQueue
oimReconQueue
oimSODQueue

The Design Console and Remote Manager configuration is stored is the xlconfig.xml file.

8.9.1.6 External Dependencies

Oracle Identity Manager is a Java EE application that is deployed on an Oracle WebLogic Managed Server. Oracle Identity Manager uses the Worklist and Human workflow modules of the Oracle SOA Suite for request flow management. Oracle Identity Manager interacts with external repositories to store configuration and runtime data. Oracle Identity Manager requires these repositories to be available during initialization and during runtime. All Oracle Identity Manager credentials are stored in the OIM repository. The external components required for the Oracle Identity Manager server to function are listed below:

Oracle WebLogic Server
- Administration Server
- Managed Server
Data Repositories
- Configuration Repository (MDS Schema)
- Runtime Repository (OIM Schema)
- User Repository (OIM Schema)
External LDAP Stores (when using LDAP Sync)
BI Publisher

The Design Console is a tool used by the administrator for development and customization. The Design Console communicates directly with the Oracle Identity Manager engine, so it relies on the same components that the Oracle Identity Manager server relies on.

Remote Manager is an optional independent standalone application, which calls the custom APIs on the local system. So it needs the JAR files for those custom APIs in its classpath.

8.9.1.7 Oracle Identity Manager Log File Locations

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

The Oracle WebLogic Server log files are located under the following directory:

DOMAIN_HOME/servers/serverName/logs

The three main log files are serverName.log, serverName.out, and serverName-diagnostic.log, where serverName is the name of the Oracle WebLogic Server. For example, if the Oracle WebLogic Server name is wls_OIM1, then the diagnostic log file name would be wls_OIM1-diagnostic.log.

You can view the log files using the Oracle Enterprise Manager Fusion Middleware Control.

8.9.2 Oracle Identity Manager High Availability Concepts

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

Note:

Be aware of the following when you deploy Oracle Identity Manager in a high availability configuration:

Oracle Identity Manager can be deployed on an Oracle RAC database, but Oracle RAC failover is not transparent for Oracle Identity Manager in this release. If an Oracle RAC failover occurs, end users may have to resubmit their requests.
Oracle Identity Manager always requires that at least one of the nodes in the SOA cluster be available. If the SOA cluster is not available, end user requests will fail. Oracle Identity Manager does not retry for a failed SOA call. Therefore, the end user must retry when a SOA call fails.

8.9.2.1 Oracle Identity Manager High Availability Architecture

Figure 8-15 shows Oracle Identity Manager deployed in a high availability architecture in an active-active configuration.

Figure 8-15 Oracle Identity Manager High Availability Architecture

Description of "Figure 8-15 Oracle Identity Manager High Availability Architecture"

On OIMHOST1, the following installations have been performed:

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

On OIMHOST2, the following installations have been performed:

An Oracle Identity Manager instance has been installed in the WLS_OIM2 Managed Server and a SOA instance has been installed in the WLS_SOA2 Managed Server.
The Oracle RAC database has been configured in a JDBC multi data source to protect the instance from Oracle RAC node failure.
The instances in the WLS_OIM1 and WLS_OIM2 Managed Servers on OIMHOST1 and OIMHOST2 are configured as the OIM_Cluster cluster.
The instances in the WLS_SOA1 and WLS_SOA2 Managed Servers on OIMHOST1 and OIMHOST2 are configured as the SOA_Cluster 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 OIMHOST1 becomes unavailable.

The following virtual host names are used in the Oracle Identity Manager high availability configuration in Figure 8-15:

OIMVHN1 is the virtual host name that maps to the listen address for the WLS_OIM1 managed server, and it fails over with server migration of the WLS_OIM1 managed server. It is enabled on the node where the WLS_OIM1 managed server is running (OIMHOST1 by default).
OIMVHN2 is the virtual host name that maps to the listen address for the WLS_OIM2 managed server, and it fails over with server migration of the WLS_OIM2 managed server. It is enabled on the node where the WLS_OIM2 managed server is running (OIMHOST2 by default).
SOAVHN1 is the virtual host name that is the listen address for the WLS_SOA1 managed server, and it fails over with server migration of the WLS_SOA1 managed server. It is enabled on the node where the WLS_SOA1 managed server is running (OIMHOST1 by default).
SOAVHN2 is the virtual host name that is the listen address for the WLS_SOA2 managed server, and it fails over with server migration of the WLS_SOA2 managed server. It is enabled on the node where the WLS_SOA2 managed server is running (OIMHOST2 by default).
VHN refers to the virtual IP addresses for the Oracle Real Application Clusters (Oracle RAC) database hosts.

8.9.2.2 Starting and Stopping the Oracle Identity Manager Cluster

In a high availability architecture, Oracle Identity Manager is deployed on an Oracle WebLogic cluster that has at least two servers as members of the cluster.

By default, Oracle WebLogic Server starts, stops, monitors, and manages the various lifecycle events for the application. The Oracle Identity Manager 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.

You can use one or more of the following command line tools and consoles to manage Oracle Identity Manager lifecycle events:

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

8.9.2.3 Cluster-Wide Configuration Changes

For high availability environments, changing the configuration of one Oracle Identity Manager instance changes the configuration of all the other instances, because all the Oracle Identity Manager instances share the same configuration repository.

8.9.2.4 Considerations for Synchronizing with LDAP

Synchronization information between LDAP and the Oracle Identity Manager database is handled by a process called Reconciliation, which is a scheduled process that runs in the background primarily. It is also possible to manually run this process.

If an LDAP outage occurs during the Synchronization process, the data which did not get into Oracle Identity Manager will be picked up during the next run of the reconciliation task.

8.9.3 Oracle Identity Manager High Availability Configuration Steps

This section provides high-level instructions for setting up a high availability deployment for Oracle Identity Manager.

This section includes the following topics about configuring Oracle Identity Management for high availability:

Section 8.9.3.1, "Prerequisites for Oracle Identity Manager Configuration"
Section 8.9.3.2, "Creating and Configuring the WebLogic Domain for OIM and SOA on OIMHOST1"
Section 8.9.3.3, "Post-Installation Steps on OIMHOST1"
Section 8.9.3.4, "Configuring Oracle Identity Manager on OIMHOST1"
Section 8.9.3.5, "Post-Configuration Steps for the Managed Servers"
Section 8.9.3.6, "Validate the Oracle Identity Manager Instance on OIMHOST1"
Section 8.9.3.7, "Propagating Oracle Identity Manager to OIMHOST2"
Section 8.9.3.8, "Post-Installation Steps on OIMHOST2"
Section 8.9.3.9, "Validate the Oracle Identity Manager Instance on OIMHOST2"
Section 8.9.3.10, "Configuring Oracle Internet Directory using the LDAP Configuration Post-setup Script"
Section 8.9.3.11, "Configuring Node Manager on OIMHOST1 and OIMHOST2"
Section 8.9.3.12, "Configuring Server Migration for the OIM and SOA Managed Servers"
Section 8.9.3.13, "Configuring a Shared JMS Persistence Store"
Section 8.9.3.14, "Configuring a Default Persistence Store for Transaction Recovery"
Section 8.9.3.15, "Install Oracle HTTP Server on WEBHOST1 and WEBHOST2"
Section 8.9.3.16, "Configuring Oracle Identity Manager to Work with the Web Tier"
Section 8.9.3.17, "Validate the Oracle HTTP Server Configuration"
Section 8.9.3.18, "Oracle Identity Manager Failover and Expected Behavior"
Section 8.9.3.19, "Troubleshooting Oracle Identity Manager High Availability"
Section 8.9.3.20, "Scaling Up and Scaling Out the Oracle Identity Manager Topology"

8.9.3.1 Prerequisites for Oracle Identity Manager Configuration

Before you configure Oracle Identity Manager for high availability, you must:

Run the Repository Creation Utility to create the OIM schemas in a database.

See Section 8.9.3.1.1, "Running RCU to Create the OIM Schemas in a Database" for instructions on running the Repository Creation Utility to create the OIM schemas.
Install Oracle WebLogic Server on OIMHOST1 and OIMHOST2

Follow the steps in Section 8.9.3.1.2, "Installing Oracle WebLogic Server" to install Oracle WebLogic Server on OIMHOST1 and OIMHOST2.
Install the Oracle SOA Suite on OIMHOST1 and OIMHOST2.

Follow the steps in Section 8.9.3.1.3, "Installing the Oracle SOA Suite on OIMHOST1 and OIMHOST2" to install the Oracle SOA Suite software on OIMHOST1 and OIMHOST2.
Upgrade Oracle SOA Suite on OIMHOST1 and OIMHOST2

Follow the steps in Section 8.9.3.1.4, "Upgrading the Oracle SOA Suite on OIMHOST1 and OIMHOST2" to upgrade the Oracle SOA Suite on OIMHOST1 and OIMHOST2.
Install the Oracle Identity Management software on OIMHOST1 and OIMHOST2:

Follow the steps in Section 8.9.3.1.5, "Installing the Oracle Identity Manager on OIMHOST1 and OIMHOST2" to install the Oracle Identity Management software on OIMHOST1 and OIMHOST2.
Make sure that a highly available LDAP implementation is available.

Note:
This section is required only for LDAPSync-enabled Oracle Identity Manager installations and for Oracle Identity Manager installations that integrate with Oracle Access Manager.
If you are not planning to enable the LDAPSync option or to integrate with Oracle Access Manager, you can skip this section.

For information about installing and configuring Oracle Internet Directory, see Section 8.3.3, "Oracle Internet Directory High Availability Configuration Steps." For information about installing and configuring Oracle Virtual Directory, see Section 8.4.3, "Oracle Virtual Directory High Availability Configuration Steps." Note that Oracle Identity Manager does not communicate directly with Oracle Internet Directory. It communicates with Oracle Virtual Directory, which communicates with Oracle Internet Directory.
Create the wlfullclient.jar file

Oracle Identity Manager uses the wlfullclient.jar library for certain operations. Oracle does not ship this library, so you must create this library manually. Oracle recommends creating this library under the MW_HOME/wlserver_10.3/server/lib directory on all the machines in the application tier of your environment. You do not need to create this library on directory tier machines such as OIDHOST1, OIDHOST2, OVDHOST1 and OVDHOST2.

Follow these steps to create the wlfullclient.jar file:
1. Navigate to the MW_HOME/wlserver_10.3/server/lib directory.
2. Set your JAVA_HOME to MW_HOME/jdk160_18 and ensure that your JAVA_HOME/bin directory is in your path.
3. Create the wlfullclient.jar file by running:
  
  java -jar wljarbuilder.jar

8.9.3.1.1 Running RCU to Create the OIM Schemas in a Database

Before you can install the Oracle Identity Manager and SOA instances on OIMHOST1 and OIMHOST2, you must use the Repository Creation Utility (RCU) to create the collection of schemas used by Oracle Identity Manager.

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 Manager schemas in an Oracle 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 the 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 an Oracle RAC database, specify the VIP name or one node name. Example: OIMDBHOST1-VIP or OIMDBHOST2-VIP
- Port: The port number for the database. For example: 1521
- Service Name: The service name of the database. For example: oim.mycompany.com
- Username: SYS
- Password: The SYS user password
- Role: SYSDBA
Click Next.
Click OK on the Checking Prerequisites screen after the Global Prerequisites complete successfully.
On the Select Components screen, create a new prefix and select the components to be associated with this deployment:

Create a New Prefix: ha

Components:
- Under Identity Management:
  - Oracle Identity Manager - OIM
  - Note that Metadata Services - MDS is selected by default.
- Under SOA and BAM Infrastructure:
  - SOA Infrastructure - SOAINFRA
  - User Messaging Service - ORASDPM
Click Next.
Click OK on the Checking Prerequisites screen after the Component Prerequisites complete successfully.
On the Schema Passwords screen, enter the passwords for the mail and additional (auxiliary) schema users.

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

8.9.3.1.2 Installing Oracle WebLogic Server

Start the installer, then perform these steps on OIMHOST1 and OIMHOST2:

On the Welcome screen, click Next.
On the Choose Middleware Home Directory screen, select Create a New Middleware Home.

For Middleware Home Directory, enter:

ORACLE_BASE/product/fmw

Note:
ORACLE_BASE is the base directory under which Oracle products are installed. The recommended value is /u01/app/oracle.

Click Next.
On the Register for Security Updates screen, enter your contact information so that you can be notified of security updates.

Click Next.
On the Choose Install Type screen, select Custom.

Click Next.
On the Choose Products and Components screen, select only Oracle JRockit SDK, and click Next.
On the Choose Product Installation Directories screen, accept the directory ORACLE_BASE/product/fmw/wlserver_10.3.

Click Next.
On the Installation Summary screen, click Next.
On the Installation Complete screen, deselect Run Quickstart.

Click Done.

8.9.3.1.3 Installing the Oracle SOA Suite on OIMHOST1 and OIMHOST2

Perform these steps to install Oracle Fusion Middleware Components on OIMHOST1 and OIMHOST2.

Start the installer for Oracle Fusion Middleware Component as follows:

HOST1> runInstaller

When the installer prompts you for a JRE/JDK location, enter the Oracle SDK location created in the Oracle WebLogic Server installation, for example, ORACLE_BASE/product/fmw/jrockit_160_14_R27.6.5-32.

Then proceed as follows:

On the Welcome screen, click Next.
On the Prerequisite Checks screen, verify that the checks complete successfully, then click Next.
On the Specify Installation Location screen, enter the following values:
- Oracle Middleware Home: Select the previously installed Middleware home from the list for MW_HOME, for example
  
  /u01/app/oracle/product/fmw
- Oracle Home Directory:
  - Enter soa as the Oracle home directory name when installing the Oracle SOA Suite in the ORACLE_HOME
Click Next.
On the Installation Summary screen, click Install.

When prompted, on Linux and UNIX installations, execute the script oracleRoot.sh as the root user.
On the Installation Complete screen, click Finish.

8.9.3.1.4 Upgrading the Oracle SOA Suite on OIMHOST1 and OIMHOST2

Follow the steps in this section to upgrade the SOA_ORACLE_HOME from release 11.1.1.2 to 11.1.1.4 using the Oracle SOA Suite Patch Set installer. Complete these steps on OIMHOST1 and OIMHOST2. Ensure that your machines meet all the prerequisites listed in the Oracle Fusion Middleware Upgrade Guide for Oracle SOA Suite, WebCenter, and ADF.

Start the Oracle SOA Suite Patch Set installer by typing:

HOST1> ./runInstaller

When the installer prompts you for a JRE/JDK location, enter the Oracle SDK location created in the Oracle WebLogic Server installation, for example:

ORACLE_BASE/product/fmw/jrockit_160_14_R27.6.5-32

Then proceed as follows:

On the Welcome screen, click Next.
On the Prerequisite Checks screen, verify that the checks complete successfully, then click Next.
On the Specify Installation Location screen, enter the following Values:
- Oracle Middleware Home: Select the previously installed Middleware Home from the drop-down list, for example: /u01/app/oracle/product/fmw.
- Oracle Home Directory: Enter soa as the Oracle Home Directory. This Oracle home contains the Oracle SOA Suite binaries that will be upgraded from 11.1.1.2 to 11.1.1.3.
Click Next.
On the Installation Summary screen, click Install. When prompted, on Linux and UNIX installations, execute the script oracleRoot.sh as the root user.
On the Installation Complete screen, click Finish.

8.9.3.1.5 Installing the Oracle Identity Manager on OIMHOST1 and OIMHOST2

Perform these steps to install Oracle Fusion Middleware Components on OIMHOST1 and OIMHOST2.

Start the installer for Oracle Fusion Middleware Component as follows:

HOST1> runInstaller

Then proceed as follows:

On the Welcome screen, click Next.
On the Prerequisite Checks screen, verify that the checks complete successfully, then click Next.
On the Specify Installation Location screen, enter the following values:
- Oracle Middleware Home: Select the previously installed Middleware home from the list for MW_HOME, for example
  
  /u01/app/oracle/product/fmw
- Oracle Home Directory:
  - Enter iam as the Oracle home directory name when installing the Oracle Identity and Access Management Suite in the ORACLE_HOME
Click Next.
On the Installation Summary screen, click Install.

When prompted, on Linux and UNIX installations, execute the script oracleRoot.sh as the root user.
On the Installation Complete screen, click Finish.

8.9.3.2 Creating and Conf iguring the WebLogic Domain for OIM and SOA on OIMHOST1

The domain needs to be created on OIMHOST1. Follow these steps:

Start the Configuration Wizard by executing this command:
```
MW_HOME/oracle_common/common/bin/config.sh
```
On the Welcome screen, select Create a WebLogic Domain.

Click Next.
On the Select Domain Source screen, select Generate a domain configured automatically to support the following added products.

From the list, select:
- Oracle Identity Manager
  
  Note that Oracle SOA Suite and Oracle WSM Policy Manager are selected automatically.
- Oracle Enterprise Manager
  
  Note that Oracle JRF is selected automatically.
On the Specify Domain Name and Location screen, enter the name and location for the domain and all its applications.

Provide the following:
- Domain Name: IDMDomain
- Domain Location: Accept the default.
- Application Location: Accept the default.
Click Next.
On the Configure Administration Server Username and Password screen, provide the following:
- Name: weblogic
- User Password: Enter the password for the weblogic user.
- Confirm User Password: Enter the password for the weblogic user.
- Description: Provide a description for the user.
Click Next.
On the Configure Server Start Mode and JDK screen, select Production Mode and JRockit SDK 1.6.n.

Click Next.
On the Configure JDBC Component Schemas screen, select the Component Schemas shown below:
- SOA Infrastructure
- User Messaging Service
- OIM MDS Schema
- OWSM MDS Schema
- SOA MDS Schema
- OIM Infrastructure
Select the check box next to Configure selected component schemas as RAC multi data source schemas in the next panel.

Click Next.

On the Configure RAC Multi Data Source Component Schemas screen, select all the Multi Data Source schemas and enter the following:

Service Name: oim.mycompany.com
For the first RAC node:
- Host Name: OIMDBHOST1-VIP.mycompany.com
- Instance Name: oimdb1
- Port: 1521
For the second RAC node:
- Host Name: OIMDBHOST2-VIP.mycompany.com
- Instance Name: oimdb2
- Port: 1521

Select each schema individually and enter the schema's username and password, as shown in Table 8-7:

Table 8-7 Entering the Schema Owner and Password for Each multi data Source Schema

Schema Name	Schema Owner	Password
SOA Infrastructure	HA_SOAINFRA	<enter the password>
User Messaging Service	HA_ORASDPM	<enter the password>
OIM MDS Schema	HA_MDS	<enter the password>
OWSM MDS Schema	HA_MDS	<enter the password>
SOA MDS Schema	HA_MDS	<enter the password>
OIM Infrastructure	HA_OIM	<enter the password>

Click Next.

On the Test Component Schema screen, select All the Schemas and then click Test Connections. Validate that the test for all the schemas completed successfully.

Click Next.
On the Select Optional Configuration screen, select:
- Administration Server
- JMS Distributed Destination
- Managed Server Clusters and Machines
Click Next.
In the Configure the Administration Server screen, enter the following values:
- Name: AdminServer
- Listen Address: oimhost1.mycompany.com
- Listen Port: 7001
- SSL listen port: Not applicable
- SSL enabled: Leave unchecked
Click Next.
On the Select JMS Distributed Destination Type screen, make sure that all the JMS System Resources listed on the screen are Uniform Distributed Destinations. If they are not, select UDD from the drop down box. Validate that the entries look like those in Table 8-8:

Table 8-8 Values to Choose for JMS System Resources

JMS System Resource Uniform/Weighted Distributed Destination

UMSJMSSystemResource

UDD

SOAJMSModule

UDD

OIMJMSModule

UDD

Click Next.

An Override Warning box with the following message is displayed:

"CFGFWK-40915: At least one JMS system resource has been selected for conversion to a Uniform Distributed Destination (UDD). This conversion will take place only if the JMS System resource is assigned to a cluster."

Click OK on the Warning popup box.
When you first enter the Configure Managed Servers screen, the configuration wizard will have created two default managed servers (oim_server1 and soa_server1) for you. Change the details of the default managed servers and then add the second managed server. Follow the steps below:

For the oim_server1 entry, change the entry to the following values:
- Name: WLS_OIM1
- Listen Address: OIMVHN1
- Listen Port: 14000
For the soa_server1 entry, change the entry to the following values:
- Name: WLS_SOA1
- Listen Address: SOAVHN1
- Listen Port: 8001
For the second OIM Server, click Add and supply the following information:
- Name: WLS_OIM2
- Listen Address: OIMVHN2
- Listen Port: 14000
For the second SOA Server, click Add and supply the following information:
- Name: WLS_SOA2
- Listen Address: SOAVHN2
- Listen Port: 8001
Click Next.

Note:
Follow the steps for adding the second managed server to add additional managed servers.
On the Configure Clusters screen, create two clusters by clicking Add.

Supply the following information for the OIM Cluster:
- Name: oim_cluster
- Cluster Messaging Mode: unicast
Supply the following information for the SOA Cluster:
- Name: soa_cluster
- Cluster Messaging Mode: unicast
Leave all the other fields at the default settings and click Next.
On the Assign Servers to Clusters screen, associate the managed servers with the cluster. Click on the cluster name in the right window.

Click on the managed server under servers, then click on the arrow to assign it to the cluster.

Assign the WLS_OIM1 and WLS_OIM2 managed servers to be members of the oim_cluster.

Assign the WLS_SOA1 and WLS_SOA2 managed servers to be members of the soa_cluster.

Click Next.
On the Configure Machines screen, create a machine for each host in the topology.

Click on the Unix tab if your hosts use some type of Unix operating system. Otherwise, click on Machines.

Provide the following information:
- Name: Name of the host. A good practice is to use the DNS name here.
- Node Manager Listen Address: Enter the DNS name of the machine here.
- Node Manager Port: Supply a port for Node Manager to use.
Click Next.

Note:
On UNIX, delete the default local machine entry under the Machines tab.
On the Assign Servers to Machines screen, you will assign the managed servers that will run on the machines you just created. Follow these steps:

Click on a machine in the right hand window.

Click on the managed servers you want to run on that machine in the left window.

Click on the arrow to assign the managed servers to the machine.

Repeat these steps until all the managed servers are assigned to the appropriate machine.

A typical example would be:
- Host1: Admin Server, WLS_OIM1, and WLS_SOA1
- Host2: WLS_OIM2 and WLS_SOA2
Click Next.
On the Configuration Summary screen, click Create to create the domain.

JMS System Resource	Uniform/Weighted Distributed Destination
UMSJMSSystemResource	UDD
SOAJMSModule	UDD
OIMJMSModule	UDD

8.9.3.3 Post-Installation Steps on OIMHOST1

This section describes the post-installation steps to perform on OIMHOST1. It includes these sections:

Section 8.9.3.3.1, "Creating boot.properties for the Administration Server on OIMHOST1"
Section 8.9.3.3.2, "Update Node Manager on OIMHOST1"
Section 8.9.3.3.3, "Start Node Manager on OIMHOST1"
Section 8.9.3.3.4, "Start the Administration Server on OIMHOST1"

8.9.3.3.1 Creating boot.properties for the Administration Server on OIMHOST1

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

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

For example:

$ mkdir -p 
MW_HOME/user_projects/domains/domainName/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.

8.9.3.3.2 Update Node Manager on OIMHOST1

Before the managed servers can be started via the WebLogic Administration Console, Node Manager requires that the StartScriptEnabled property be set to true.

To do this, run the setNMProps.sh script located under the following directory:

MW_HOME/oracle_common/common/bin

8.9.3.3.3 Start Node Manager on OIMHOST1

Start the Node Manager on OIMHOST1 using the startNodeManager.sh script located under the following directory:

MW_HOME/wlserver_10.3/server/bin

8.9.3.3.4 Start the Administration Server on OIMHOST1

Follow these steps to start the Administration Server and validate its startup:

Start the Administration Server on OIMHOST1 by issuing the command:
```
DOMAIN_HOME/bin/startWebLogic.sh
```
Validate that the Administration Server started up successfully by opening a web browser and accessing the following pages:
- WebLogic Server Administration Console at:
```
http://oimhost1.mycompany.com:7001/console
```
- Oracle Enterprise Manager Fusion Middleware Control at:
```
http://oimhost1.mycompany.com:7001/em
```
Log into these consoles using the weblogic user credentials.

8.9.3.4 Configuring Oracle Identity Manager on OIMHOST1

This section describes how to configure the Oracle Identity Manager and SOA managed servers before starting them.

This section includes the following topics:

Section 8.9.3.4.1, "Prerequisites for Configuring Oracle Identity Manager"
Section 8.9.3.4.2, "Running the Oracle Identity Management Configuration Wizard"

8.9.3.4.1 Prerequisites for Configuring Oracle Identity Manager

Before configuring Oracle Identity Manager, ensure that the following tasks have been performed:

Note:

This section is required only for LDAPSync-enabled Oracle Identity Manager installations and for Oracle Identity Manager installations that integrate with Oracle Access Manager.

If you are not planning to enable the LDAPSync option or to integrate with Oracle Access Manager, you can skip this section.

Configure Oracle Internet Directory using the LDAP configuration pre-setup script, as described in "Configuring Oracle Internet Directory using the LDAP Configuration Pre-setup Script".
Create the Adapters in Oracle Virtual Directory, as described in "Creating Adapters in Oracle Virtual Directory".

Configuring Oracle Internet Directory using the LDAP Configuration Pre-setup Script

The Oracle Identity Manager LDAP configuration pre-setup script adds the users, group and schemas required by Oracle Identity Manager in Oracle Internet Directory. The LDAP configuration pre-setup script is located under the IAM_ORACLE_HOME/server/ldap_config_util directory. To run the script, follow these steps:

Edit the ldapconfig.props file located under the IAM_ORACLE_HOME/server/ldap_config_util directory and provide the following values:

Parameter	Value
`OIMProviderURL`	`t3://oimvhn1.mycompany.com:14000,oimvhn2.mycompany.com:14000`
`OIDURL`	`ldap://oidhost1.mycompany.com:389`
`OIDAdminUsername`	`cn=orcladmin`
`OIDSearchBase`	`dc=mycompany,dc=com`
`UserContainerName`	`cn=Users`
`RoleContainerName`	`cn=Roles`
`ReservationContainerName`	`cn=Reserved`

Note:

The OIMProviderURL is not used by the LDAP configuration pre-setup script. It is only used by the LDAP configuration post-setup script.
The OIDURL above refers to the OID URL. Do not substitute the OVD URL.
The script throws a warning message if a container already exists in OID. You can safely ignore this message.

Save the file.

Set the JAVA_HOME and the WL_HOME.

JAVA_HOME=ORACLE_BASE/product/fmw/jdk160_18
WL_HOME=ORACLE_BASE/product/fmw/wlserver_10.3

Note:

The JAVA_HOME must be set to the SUN JDK.

Run LDAPConfigPreSetup.sh. The script prompts for the Oracle Internet Directory administrator password and the Oracle Identity Manager administrator password. For example:

Prompt> ./LDAPConfigPreSetup.sh
[Enter OID admin password:]
[Enter OIM admin password:]

where OID admin password is the password for the Administrative account for managing Oracle Internet Directory and OIM admin password is the password for the Administrative LDAP account to be created in the LDAP repository for use by Oracle Identity Manager for LDAP-Sync required actions.

Note:

The LDAPConfigPre script creates a user called oimadmin with the following DN in Oracle Internet Directory: dn: cn=oimadmin,cn=users,cn=oim,cn=products,cn=oraclecontext. Oracle Identity Manager uses this user for the LDAP sync operations.

You use the credentials for the oimadmin user when you create the adapters in OVD. Please make a note of the password provided here

The Output will be similar to this:

./LDAPConfigPreSetup.sh 
[Enter OID admin password:]
[Enter OIM admin password:]
Jun 21, 2010 6:16:18 PM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING:  ./oimadminuser.ldif
Jun 21, 2010 6:16:20 PM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING:  ./oimcontainers.ldif
Jun 21, 2010 6:16:20 PM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING:  ../../oam/server/oim-intg/schema/OID_oblix_schema_add.ldif
Jun 21, 2010 6:16:48 PM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING:  ../../oam/server/oim-intg/schema/OID_oblix_schema_index_add.ldif


Jun 21, 2010 6:26:03 PM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING:  ../../oam/server/oim-intg/schema/OID_oblix_pwd_schema_add.ldif
Jun 21, 2010 6:26:04 PM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING:  ../../oam/server/oim-intg/schema/OID_oim_pwd_schema_add.ldif

Validate that the script completed successfully.

Creating Adapters in Oracle Virtual Directory

Oracle Identity Manager uses Oracle Virtual Directory to connect to external LDAP stores. You must create a user adapter and a change log adapter in Oracle Virtual Directory to enable Oracle Identity Manager to connect to the external LDAP store, such as Oracle Internet Directory. Follow these steps to create the adapters.

User Adapter

Create the user adapter on the Oracle Virtual Directory instances running on OVDHOST1 and OVDHOST2 individually. Follow these steps to create the User Adapter in Oracle Virtual Directory using Oracle Directory Services Manager.

Open a browser and bring up the ODSM console at http://admin.mycompany.com/odsm.

Note:
Although Oracle Directory Services Manager is not shown in Figure 8-15, it is required to managed Oracle Internet Directory and Oracle Virtual Directory. It is assumed that Oracle Directory Services Manager exists in your environment.
Create connections to each of the Oracle Virtual Directory instances running on OVDHOST1 and OVDHOST2, if they do not already exist
Connect to each Oracle Virtual Directory instance by using the appropriate connection entry.
On the Home page, click the Adapter tab.
Start the New Adapter Wizard by clicking Create Adapter at the top of the adapter window.

Create a new adapter using the New Adapter Wizard, with the following parameters:

Note:

If you created a User Adapter previously, skip the steps to create the Adapter and follow the steps to edit the Adapter.

Screen	Field	Value/Step
Type	Adapter Type	`LDAP`
	Adapter Name	`User Adapter`
	Adapter Template	`User_OID`
Connection	Use DNS Setting	No
	Host	`oid.mycompany.com`
	Port	`389`
	Server Proxy Bind DN	`cn=oimadmin,cn=users,cn=oim,cn=products,cn=oraclecontext`
	Proxy Password	`oimadmin` password. This is same as the password provided in "Configuring Oracle Internet Directory using the LDAP Configuration Pre-setup Script".
Connection Test		Validate that the test succeeds.
Namespace	Remote Base	`dc=mycompany,dc=com`
	Mapped Namespace	`dc=mycompany,dc=com`
Summary		Verify that the summary is correct and then click Finish.

Edit the User Adapter as follows:
1. Select the OIM User Adapter.
2. Click the Plug-ins Tab.
3. Click the User Management Plug-in, then click Edit in the plug-ins table. The plug-in editing window appears.
4. In the Parameters table, update the parameter values as follows:
  
  Parameter value
  
  directoryType oid
  
  pwdMaxFailure 10
  
  oamEnabled true
5. Click OK.
6. Click Apply.

Parameter	value
directoryType	oid
pwdMaxFailure	10
oamEnabled	true

Change Log Adapter

Create the change log adapter on the Oracle Virtual Directory instances running on OVDHOST1 and OVDHOST2 individually. Follow these steps to create the Change Log Adapter in Oracle Virtual Directory using Oracle Directory Services Manager.

Open a browser and bring up the ODSM console at http://admin.mycompany.com/odsm.
Create connections to each of the Oracle Virtual Directory instances running on OVDHOST1 and OVDHOST2, if they do not already exist.
Connect to an Oracle Virtual Directory instance by using the appropriate connection entry.
On the Home page, click on the Adapter tab.
Start the New Adapter Wizard by clicking Create Adapter at the top of the adapter window.

Create a new adapter using the New Adapter Wizard, with the following parameters:

Screen	Field	Value/Step
Type	Adapter Type	LDAP
	Adapter Name	OIM Change Log Adapter
	Adapter Template	`Changelog_OID`
Connection	Use DNS Setting	No
	Host	`oid.mycompany.com`
	Port	`389`
	Server Proxy Bind DN	`cn=oimadmin,cn=users,cn=oim,cn=products,cn=oraclecontext`
	Proxy Password	`oimadmin` password. This is same as the password provided in "Configuring Oracle Internet Directory using the LDAP Configuration Pre-setup Script".
Connection Test		Validate that the test succeeds.
Naming Space	Remote Base	`cn=changelog`
Mapped Namespace		`cn=changelog`
Summary		Verify that the summary is correct, then click Finish.

To edit the change adapter, follow these steps.

Select the OIM Change Log Adapter.
Click the Plug-ins tab.
In the Deployed Plus-ins table, click the changelog plug-in, then click "Edit in the plug-ins table. The plug-in editing window appears.
In the Parameters table, update the parameter values.
Click OK.
Click Apply.

Edit the Change Log Adapter to either add or modify the properties so that they match the values shown in the following table. You must add the mapObjectclass, modifierDNFilter, sizeLimit, and targetDNFilter proprieties to the adapter.

Parameter	Value
directoryType	`oid`
mapAttribute	`targetGUID=orclGUID`
mapObjectclass	`changelog=changelogentry`
requiredAttribute	`orclGUID`
addAttribute	`orclContainerOC,changelogSupported=1`
modifierDNFilter	`cn=oimadmin,cn=users,cn=OIM,cn=Products,cn=OracleContext`
sizeLimit	`1000`
targetDNFilter	`dc=mycompany,dc=com` Search based from which reconciliation needs to happen. This value must be the same as the LDAP SearchDN that is specified during OIM installation.
mapUserState	`true`
oamEnabled	`true`

Stopping and Starting Oracle Internet Directory and Oracle Virtual Directory

Stop and Start:

The Oracle Virtual Directory instances running on both OVDHOST1 and OVDHOST2.
The Oracle Internet Directory instances running on both OIDHOST1 and OIDHOST2.

as described in Section 8.14, "Starting and Stopping Oracle Identity Management Components."

8.9.3.4.2 Running the Oracle Identity Management Configuration Wizard

You must configure the Oracle Identity Manager server instances before you can start the Oracle Identity Manager and SOA managed servers. These configuration steps need to be performed only once, for example, during the initial creation of the domain. The Oracle Identity Management Configuration Wizard loads the OIM metadata into the database and configures the instance.

Before proceeding, ensure that the following are true:

The administration server is up and running.
The environment variables DOMAIN_HOME and WL_HOME are not set in the current shell.

The Oracle Identity Management Configuration Wizard is located under the Identity Management Oracle home. Type:

IAM_ORACLE_HOME/bin/config.sh

Proceed as follows:

On the Welcome screen, click Next
On the Components to Configure screen, select OIM Server. Select OIM Remote Manager, if required in your topology.

Click Next.
On the Database screen, provide the following values:
- Connect String: The connect string for the OIM database. For example:
  
  oimdbhost1-vip.mycompany.com:1521:oimdb1^oimdbhost2-vip.mycompany.com:1521:oimdb2@oim.mycompany.com
- OIM Schema User Name: HA_OIM
- OIM Schema password: password
- MDS Schema User Name: HA_MDS
- MDS Schema Password: password
Select Next.
On the WebLogic Administration Server screen, provide the following details for the WebLogic Admin Server:
- URL: The URL to connect to the WebLogic Administration Server. For example: t3://oimhost1.mycompany.com:7001
- UserName: weblogic
- Password: Password for the weblogic user
Click Next.
On the OIM Server screen, provide the following values:
- OIM Administrator Password: Password for the OIM Administrator. This is the password for the xelsysadm user.
- Confirm Password: Confirm the password·
- OIM HTTP URL: Proxy URL for the OIM Server. This is the URL for the Hardware load balancer that is front ending the OHS servers for OIM. For example: http://oiminternal.mycompany.com:80.
- Key Store Password: Key store password. The password must have an uppercase letter and a number. For example: MyPassword1
Click Next.
On the LDAP Sync and OAM screen, select Configure BI Publisher and provide the BI Publisher URL, if required in your environment. Enter the URL to connect to the BI Publisher in your environment.

Select Enable LDAP Sync.

Note:
If LDAP Sync is not needed, then do not select the Enable LDAP Sync option - step 7 and Step 8 are applicable only when the LDAP Sync option is enabled.
Notes:
- Do not select Enable Identity Administration Integration with OAM.
- BI Publisher is not a part of the IDMDomain. For information about BI Publisher high availability, see Section 15.2, "High Availability for Oracle Business Intelligence Publisher."
Click Next.
On the LDAP Server screen, provide the following LDAP server details:

Note:
This release of Oracle Identity Manager LDAPSync module supports connecting to Oracle Internet Directory only through the Oracle Virtual Directory.
The LDAP server referred to in this step and the next step is an Oracle Virtual Directory.
- LDAP URL : The URL to access the LDAP server. For example: ldap://ovd.mycompany.com:389
- LDAP User : The username to connect to the LDAP Server. For example: cn=orcladmin·
- LDAP Password: The password to connect to the LDAP server.
- LDAP SearchDN: The Search DN. For example: dc=mycompany,dc=com.
Click Next.
On the LDAP Server Continued screen, provide the following LDAP server details:
- LDAP Role Container: The DN for the Role Container. This is the container where the OIM roles are stored. For example: cn=Roles,dc=mycompany,dc=com ·
- LDAP User Container: The DN for the User Container. This is the container where the OIM users are stored. For example: cn=Users,dc=mycompany,dc=com·
- User Reservation Container: The DN for the User Reservation Container. For example: cn=Reserved,dc=mycompany,dc=com.
Note:
These container values should be the same as those used in LDAPConfigPreSetup.sh.

Click Next.
On the Remote Manager screen, provide the following values:

Note:
This screen appears only if you selected the Remote Manager utility in step 2.
- Service Name: HA_RManager
- RMI Registry Port: 12345
- Listen Port (SSL): 12346
On the Configuration Summary screen, verify the summary information.

Click Configure to configure the Oracle Identity Manager instance.
On the Configuration Progress screen, once the configuration completes successfully, click Next.
On the Configuration Complete screen, view the details of the Oracle Identity Manager Instance configured.

Click Finish to exit the Configuration Assistant.
Stop the WebLogic Administration Server, as described in Section 8.14, "Starting and Stopping Oracle Identity Management Components."
Start the WebLogic Administration Server, as described in Section 8.14, "Starting and Stopping Oracle Identity Management Components."

8.9.3.5 Post-Configuration Steps for the Managed Servers

This section describes the post-configuration steps for the managed servers. It includes these sections:

Section 8.9.3.5.1, "Start the WLS_SOA1 and WLS_OIM1 Managed Servers on OIMHOST1"
Section 8.9.3.5.2, "Update the DeploymentMode for Oracle Identity Manager"
Section 8.9.3.5.3, "Updating the Coherence Configuration for the Coherence Cluster"

8.9.3.5.1 Start the WLS_SOA1 and WLS_OIM1 Managed Servers on OIMHOST1

Follow these steps to start the WLS_SOA1 and WLS_OIM1 managed servers on OIMHOST1:

Stop the WebLogic Administration Server on OIMHOST1. Use the WebLogic Administration Console to stop the Administration Server.
Start the WebLogic Administration Server on OIMHOST1 using the startWebLogic.sh script under the $DOMAIN_HOME/bin directory. For example:
```
/u01/app/oracle/admin/OIM/bin/startWebLogic.sh > /tmp/admin.out 2>1&
```
Validate that the WebLogic Administration Server started up successfully by bringing up the WebLogic Administration Console.
Start the WLS_SOA1 managed server using the WebLogic Administration Console.
Start the WLS_OIM1 managed server using the WebLogic Administration Console.

8.9.3.5.2 Update the DeploymentMode for Oracle Identity Manager

By default, the Oracle Identity Manager deploymentMode is set to simple. For Oracle Identity Manager to work properly when deployed in a clustered environment, the deploymentMode must be set to cluster. Follow the steps below to update the deploymentMode using the command line MDS Utilities:

Use the Oracle Identity Manager Export Metadata tool to export the /db/oim-config.xml from the MDS repository. The Oracle Identity Manager Export Metadata Tool, weblogicExportMetadata.sh, is located under the IAM_ORACLE_HOME/server/bin directory.

Before the tool can be executed, update the weblogic.properties file under the IAM_ORACLE_HOME/server/bin directory as shown below:

# Weblogic Server Name on which OIM application is running
 
wls_servername=wls_oim1
 
# If you are importing or exporting any out of box event handlers,
# value is oim.
# For rest of the out of box metadata, value is OIMMetadata.
# If you are importing or exporting any custom data, always use application
# name as OIMMetadata.
 
application_name=oim
 
# Directory location from which XML file should be imported.
# Lets say I want to import User.xml and it is in the location
# /scratc/asmaram/temp/oim/file/User.xml.
# 
# I should give from location value as /scratc/asmaram/temp/oim. Make sure no
# other files exist
# in this folder or in its sub folders. Import utility tries to recursively 
# import all the files under the from location folder. This property is only
# used by weblogicImportMetadata.sh
 
metadata_from_loc=@metadata_from_loc
 
# Directory location to which XML file should be exported to
 
metadata_to_loc=/home/oracle/oim_export
 
# For example /file/User.xml to export user entity definition. You can specify
# multiple xml files as comma separated values.
# This property is only used by weblogicExportMetadata.sh and 
# weblogicDeleteMetadata.sh scripts
 
metadata_files=/db/oim-config.xml
 
# Application version
application_version=11.1.1.3.0

Set the OIM_ORACLE_HOME variable to the Identity Management Oracle Home.
```
prompt> export OIM_ORACLE_HOME=/u01/app/oracle/product/fmw/iam
```
Run the OIM Export Metadata Tool as shown below:
```
prompt>./weblogicExportMetadata.sh
```

Provide the values for the username, password and the server URL when prompted.

Please enter your username [weblogic] :Enter the admin user name for the 
Weblogic Domain, For Example: weblogic
Please enter your password [welcome1] : Enter the password for the Admin User
Please enter your server URL [t3://localhost:7001]  Enter the URL to connect
to Managed Server. For Example:t3://oimvhn1.mycompany.com:14000

The Output from the tool will be similar to:

Initializing WebLogic Scripting Tool (WLST) ...
 
Welcome to WebLogic Server Administration Scripting Shell
 
Type help() for help on available commands
 
Starting export metadata script ....
Please enter your username [weblogic] :weblogic
Please enter your password [welcome1] :
Please enter your server URL [t3://localhost:7001] :t3://oimvhn1.mycompany.com:14000
Connecting to t3://oimvhn1.mycompany.com:14000 with userid weblogic ...
Successfully connected to managed Server 'wls_oim2' that belongs to domain 
'IDMDomain'.
 
Warning: An insecure protocol was used to connect to the
server. To ensure on-the-wire security, the SSL port or
Admin port should be used instead.
 
Location changed to custom tree. This is a writable tree with No root.
For more help, use help(custom)
 
 
Disconnected from weblogic server: wls_oim2
End of export metadata script ...
 
 
Exiting WebLogic Scripting Tool.

Edit the oim-config.xml file created under the /home/oracle/db directory and update the value of deploymentMode to cluster as shown:
```
<deploymentMode>cluster</deploymentMode>
```

Update the value of the metadata_to_loc property in the weblogic.properties file under the OIM_ORACLE_HOME/server/bin directory as shown below:

# Weblogic Server Name on which OIM application is running
 
wls_servername=wls_oim1
 
# If you are importing or exporting any out of box event handlers, value is
# oim.
# For rest of the out of box metadata, value is OIMMetadata.
# If you are importing or exporting any custom data, always use application 
# name as OIMMetadata.
 
application_name=oim
 
# Directory location from which XML file should be imported.
# Lets say I want to import User.xml and it is in the location 
# /scratc/asmaram/temp/oim/file/User.xml,
# I should give from location value as /scratc/asmaram/temp/oim. Make sure no
# other files exist in this folder or its sub folders. Import utility tries to
# recursively import all the files under the from location folder. This 
# property is only used by weblogicImportMetadata.sh
 
metadata_from_loc=/home/oracle/oim_export
 
# Directory location to which XML file should be exported to
 
metadata_to_loc=/home/oracle/oim_export
 
# For example /file/User.xml to export user entity definition. You can specify 
# multiple xml files as comma separated values.
# This property is only used by weblogicExportMetadata.sh and 
# weblogicDeleteMetadata.sh scripts
 
metadata_files=/db/oim-config.xml
 
# Application version
application_version=11.1.1.3.0

Run the OIM Import Metadata Tool as shown below:
```
 prompt>./weblogicImportMetadata.sh
```

Provide the values for the username, password and the server URL when prompted.

Please enter your username [weblogic] :Enter the admin user name for the 
Weblogic Domain, For Example: weblogic
Please enter your password [welcome1] : Enter the password for the Admin User
Please enter your server URL [t3://localhost:7001]  Enter the URL to connect to 
Managed Server. For Example: t3://oimvhn1.mycompany.com:14000

The Output from the tool will be similar to:

Initializing WebLogic Scripting Tool (WLST) ...
 
Welcome to WebLogic Server Administration Scripting Shell
 
Type help() for help on available commands
 
Starting export metadata script ....
Please enter your username [weblogic] :weblogic
Please enter your password [welcome1] :
Please enter your server URL [t3://localhost:7001] 
:t3://oimvhn1.mycompany.com:14000
Connecting to t3://oimvhn1.mycompany.com:14000 with userid weblogic ...
Successfully connected to managed Server 'wls_oim2' that belongs to domain 
'IDMDomain'.
 
Warning: An insecure protocol was used to connect to the
server. To ensure on-the-wire security, the SSL port or
Admin port should be used instead.
 
Location changed to custom tree. This is a writable tree with No root.
For more help, use help(custom)
 
Disconnected from weblogic server: wls_oim2
End of import metadata script ...
 
Exiting WebLogic Scripting Tool.

Stop and start the Oracle Identity Manager managed servers.

8.9.3.5.3 Updating the Coherence Configuration for the Coherence Cluster

Follow the steps below to update the Coherence configuration for the SOA managed servers:

Log into Oracle WebLogic Server Administration Console.
In the Domain Structure window, expand the Environment node.
Click Servers. The Summary of Servers page appears.
Click the name of the server (represented as a hyperlink) in the Name column of the table. The settings page for the selected server appears.
Click the Server Start tab.

Enter the following for WLS_SOA1 and WLS_SOA2 into the Arguments field.

For WLS_SOA1, enter the following (on a single line, without a carriage return):

-Dtangosol.coherence.wka1=soahost1vhn1 -Dtangosol.coherence.wka2=soahost2vhn1 -Dtangosol.coherence.localhost=soahost1vhn1

For WLS_SOA2, enter the following (on a single line, without a carriage return):

-Dtangosol.coherence.wka1=soahost1vhn1 -Dtangosol.coherence.wka2=soahost2vhn1 -Dtangosol.coherence.localhost=soahost2vhn1

Click Save and activate the changes.
This change requires the SOA servers to be restarted.

8.9.3.6 Validate the Oracle Identity Manager Instance on OIMHOST1

Validate the Oracle Identity Manager Server instance on OIMHOST1 by bringing up the Oracle Identity Manager Console using a web browser.

The URL for the Oracle Identity Manager Console is:

http://oimvhn1.mycompany.com:14000/oim

8.9.3.7 Propagating Oracle Identity Manager to OIMHOST2

Once the configuration has succeeded on OIMHOST1, the configuration can be propagated to OIMHOST2. This is done by packing the domain on OIMHOST1 and then unpacking it on OIMHOST2.

Follow these steps to pack the domain on OIMHOST1 and unpack it on OIMHOST2:

On OIMHOST1, invoke the pack utility in the MW_HOME/oracle_common/common/bin directory:

pack.sh -domain=MW_HOME/user_projects/domains/OIM_Domain -
template =/u01/app/oracle/admin/templates/oim_domain.jar -
template_name="OIM Domain" -managed=true

The previous step created the oim_domain.jar file in the following directory:
```
/u01/app/oracle/admin/templates
```
Copy the oim_domain.jar file from OIMHOST1 to a temporary directory on OIMHOST2.
On OIMHOST2, invoke the unpack utility in the MW_HOME/oracle_common/common/bin directory and specify the location of the oim_domain.jar file in its temporary directory:
```
unpack.sh -domain=MW_HOME/user_projects/domains/OIM_Domain -
template=/tmp/oim_domain.jar
```

8.9.3.8 Post-Installation Steps on OIMHOST2

This section describes the post-installation steps to perform on OIMHOST2. It includes these sections:

Section 8.9.3.8.1, "Update Node Manager on OIMHOST2"
Section 8.9.3.8.2, "Start Node Manager on OIMHOST2"
Section 8.9.3.8.3, "Start the WLS_SOA2 and WLS_OIM2 Managed Servers on OIMHOST2"

8.9.3.8.1 Update Node Manager on OIMHOST2

Before managed servers can be started via the WebLogic Administration Console, Node Manager requires that the StartScriptEnabled property be set to true.

To do this, run the setNMProps.sh script located under the following directory:

MW_HOME/oracle_common/common/bin

8.9.3.8.2 Start Node Manager on OIMHOST2

Start the Node Manager on OIMHOST2 using the startNodeManager.sh script located under the following directory:

MW_HOME/wlserver_10.3/server/bin

8.9.3.8.3 Start the WLS_SOA2 and WLS_OIM2 Managed Servers on OIMHOST2

Follow these steps to start the WLS_SOA2 and WLS_OIM2 managed servers on OIMHOST2:

Stop the WebLogic Administration Server on OIMHOST2. Use the WebLogic Administration Console to stop the Administration Server.
Start the WebLogic Administration Server on OIMHOST2 using the startWebLogic.sh script under the $DOMAIN_HOME/bin directory. For example:
```
/u01/app/oracle/admin/OIM/bin/startWebLogic.sh > /tmp/admin.out 2>1&
```
Validate that the WebLogic Administration Server started up successfully by bringing up the WebLogic Administration Console.
Start the WLS_SOA2 managed server using the WebLogic Administration Console.
Start the WLS_OIM2 managed server using the WebLogic Administration Console. The WLS_OIM2 managed server must be started after the WLS_SOA2 managed server is started.

8.9.3.9 Validate the Oracle Identity Manager Instance on OIMHOST2

Validate the Oracle Identity Manager Server instance on OIMHOST2 by bringing up the Oracle Identity Manager Console using a web browser.

The URL for the Oracle Identity Manager Console is:

http://oimvhn2.mycompany.com:14000/oim

8.9.3.10 Configuring Oracle Internet Directory using the LDAP Configuration Post-setup Script

Note:

This section is required only for LDAPSync-enabled Oracle Identity Manager installations and for Oracle Identity Manager installations that integrate with Oracle Access Manager.

If you are not planning to enable the LDAP-Sync option or to integrate with Oracle Access Manager, you can skip this section.

The Oracle Identity Manager LDAP configuration post-setup script updates the Oracle Identity Manager LDAP Sync scheduled jobs with the last change number from Oracle Internet Directory. The LDAP configuration post-setup script is located under the IAM_ORACLE_HOME/server/ldap_config_util directory. To run the script, follow these steps:

Make sure that the wlfullclient.jar file is created as described in Section 8.9.3.1, "Prerequisites for Oracle Identity Manager Configuration."
Edit the ldapconfig.props file located under the IAM_ORACLE_HOME/server/ldap_config_util directory and provide the following values:
- OIMProviderURL: t3://oimvhn1.mycompany.com:14000, t3://oimvhn2.mycompany.com:14000
- OIDURL: ldap://oid.mycompany.com:389
- OIDAdminUsername: cn=orcladmin
- OIDSearchBase: dc=mycompany,dc=com
- UserContainerName: OIMUsers
- RoleContainerName: OIMRoles
- ReservationContainerName: OIMReserve
Save the file.
Set the WL_HOME and JAVA_HOME environment variables.
Run LDAPConfigPostSetup.sh. The script prompts for the OID Admin Password and the OIM Admin Password. For example:
```
Prompt> ./LDAPConfigPostSetup.sh
[Enter OID admin password: ]
[Enter OIM admin password: ]
```
where OID admin password is the password for the Administrative account for managing Oracle Internet Directory and OIM admin password is the password for the Administrative LDAP account to be created in the LDAP repository for use by Oracle Identity Manager for LDAP-Sync required actions.

8.9.3.11 Configuring Node Man ager on OIMHOST1 and OIMHOST2

Node Manager enables you to start and stop the WebLogic Administration Server and the managed servers. The steps in the following sections describe how to set up Node Manager in your environment.

Section 8.9.3.3.2, "Update Node Manager on OIMHOST1"
Section 8.9.3.3.3, "Start Node Manager on OIMHOST1"
Section 8.9.3.8.1, "Update Node Manager on OIMHOST2"
Section 8.9.3.8.2, "Start Node Manager on OIMHOST2"

8.9.3.12 Configuring Server Migration for the OIM and SOA Managed Servers

For this high availability topology, Oracle recommends that you configure server migration for the WLS_OIM1, WLS_SOA1, WLS_OIM2, and WLS_SOA2 managed servers, as described in this section. The WLS_OIM1 and WLS_SOA1 managed servers on OIMHOST1 are configured to restart automatically on OIMHOST2 should a failure occur on OIMHOST1. The WLS_OIM2 and WLS_SOA2 managed servers on OIMHOST2 are configured to restart automatically on OIMHOST1 should a failure occur on OIMHOST2. In this configuration, the WLS_OIM1, WLS_SOA1, WLS_OIM2 and WLS_SOA2 servers listen on specific floating IPs that are failed over by WebLogic Server Migration.

The following steps enable server migration for the WLS_OIM1, WLS_SOA1, WLS_OIM2, and WLS_SOA2 managed servers. This allows a managed server to fail over to another node in the case of server or process failure:

Step 1: Setting Up a User and Tablespace for the Server Migration Leasing Table
Step 2: Creating a Multi Data Source Using the Oracle WebLogic Administration Console
Step 3: Editing Node Manager's Properties File
Step 4: Setting Environment and Superuser Privileges for the wlsifconfig.sh Script
Step 5: Configuring Server Migration Targets
Step 6: Testing the Server Migration

8.9.3.12.1 Setting Up a User and Tabl espace for the Server Migration Leasing Table

The first step to set up a user and tablespace for the server migration leasing table:

Note:

If other servers in the same domain have already been configured with server migration, the same tablespace and data sources can be used. In that case, the data sources and multi data source for database leasing do not need to be recreated, but they will have to be retargeted to the clusters being configured with server migration.

Create a tablespace called 'leasing'. For example, log on to SQL*Plus as the sysdba user and run the following command:

SQL> create tablespace leasing logging datafile 'DB_HOME/oradata/orcl/leasing.dbf' size 32m autoextend on next 32m maxsize 2048m extent management local;

Create a user named 'leasing' and assign to it the leasing tablespace:

SQL> create user leasing identified by welcome1;
SQL> grant create table to leasing;
SQL> grant create session to leasing;
SQL> alter user leasing default tablespace leasing;
SQL> alter user leasing quota unlimited on LEASING;

Create the leasing table usi ng the leasing.ddl script:
1. Copy the leasing.ddl file located in either the WL_HOME/server/db/oracle/817 or the WL_HOME/server/db/oracle/920 directory to your database node.
2. Connect to the database as the leasing user.
3. Run the leasing.ddl script in SQL*Plus:
```
SQL> @Copy_Location/leasing.ddl;
```

8.9.3.12.2 Creating a Multi Data Source Usi ng the Oracle WebLogic Administration Console

The second step is to create a multi data source for the leasing table from the Oracle WebLogic Server Administration Console. You create a data source to each of the Oracle RAC database instances during the process of setting up the multi data source, both for these data sources and the global leasing multi data source. When you create a data source:

Make sure that this is a non-XA data source.
The names of the multi data sources are in the format of <MultiDS>-rac0, <MultiDS>-rac1, and so on.
Use Oracle's Driver (Thin) Version 9.0.1, 9.2.0, 10, 11.
Data sources do not require support for global transactions. Therefore, do not use any type of distributed transaction emulation/participation algorithm for the data source (do not choose the Supports Global Transactions option, or the Logging Last Resource, Emulate Two-Phase Commit, or One-Phase Commit options of the Supports Global Transactions option), and specify a service name for your database.
Target these data sources to the OIM_CLUSTER and the SOA_CLUSTER.
Make sure the data source's connection pool initial capacity is set to 0 (zero). To do this, select Services, JDBC, and then Datasources. In the Datasources screen, click the Datasource Name, then click the Connection Pool tab, and enter 0 (zero) in the Initial Capacity field.

Creating a Multi Data Source

Perform these steps to create a multi data source:

Log into the Oracle WebLogic Server Administration Console at http://oimhost1.mycompany.com:7001/console using the Admin credentials.
In the Domain Structure window in the Oracle WebLogic Server Administration Console, expand the Services node, then expand the JDBC node.
Click Multi Data Sources. The Summary of JDBC Multi Data Source page is displayed.
Click Lock and Edit.
Click New. The Create a New JDBC Multi Data Source page is displayed.
Enter leasing as the name.
Enter jdbc/leasing as the JNDI name.
Select Failover as algorithm (default).
Click Next.
Select OIM_CLUSTER and SOA_CLUSTER as the targets.
Click Next.
Select non-XA driver (the default).
Click Next.
Click Create New Data Source.
Enter leasing-rac0 as the name. Enter jdbc/leasing-rac0 as the JNDI name. Enter oracle as the database type. For the driver type, select Oracle Driver (Thin) for RAC server-Instance connection Version 10,11.

Note:
When creating the multi data sources for the leasing table, enter names in the format of <MultiDS>-rac0, <MultiDS>-rac1, and so on.
Click Next.
Deselect Supports Global Transactions.
Click Next.
Enter the service name, database name (this is actually the RAC Node instance name, for example: racdb1,racdb2), host port, and password for your leasing schema.
Click Next.
Click Test Configuration and verify that the connection works.
Click Next.
Target the data source to OIM_CLUSTER and SOA cluster.
Select the data source and add it to the right screen.
Click Create a New Data Source for the second instance of your Oracle RAC database, target it to the OIM_CLUSTER and SOA_CLUSTER, repeating the steps for the second instance of your Oracle RAC database.
Add the second data source to your multi data source.
Click Activate Changes.

8.9.3.12.3 Editing Node Manager's Prope rties File

The third step is to edit Node Manager's properties file. This needs to be done for the Node Managers in both nodes (OIMHOST1 and OIMHOST2) where server migration is being configured:

Interface=eth0
NetMask=255.255.255.0
UseMACBroadcast=true

Interface: This property specifies the interface name for the floating IP (for example, eth0).

Note:
Do not specify the sub-interface, such as eth0:1 or eth0:2. This interface is to be used without :0 or :1. Node Manager's scripts traverse the different :X-enabled IPs to determine which to add or remove. For example, the valid values in Linux environments are eth0, eth1, eth2, eth3, ethn, depending on the number of interfaces configured.
NetMask: This property specifies the net mask for the interface for the floating IP. The net mask should the same as the net mask on the interface; 255.255.255.0 is used as an example in this document.
UseMACBroadcast: This property specifies whether or not to use a node's MAC address when sending ARP packets, that is, whether or not to use the -b flag in the arping command.

Verify in Node Manager's output (shell where Node Manager is started) that these properties are being used, or problems may arise during migration. You should see something like this in Node Manager's output:

...
StateCheckInterval=500
Interface=eth0
NetMask=255.255.255.0
...

Note:

The steps below are not required if the server properties (start properties) have been properly set and Node Manager can start the servers remotely.

Set the following property in the nodemanager.properties file:
- StartScriptEnabled: Set this property to 'true'. This is required to enable Node Manager to start the managed servers.
Start Node Manager on OIMHOST1 and OIMHOST2 by running the startNodeManager.sh script, which is located in the WL_HOME/server/bin directory.

Note:

When running Node Manager from a shared storage installation, multiple nodes are started using the same nodemanager.properties file. However, each node may require different NetMask or Interface properties. In this case, specify individual parameters on a per-node basis using environment variables. For example, to use a different interface (eth3) in HOSTn, use the Interface environment variable as follows: HOSTn> export JAVA_OPTIONS=-DInterface=eth3 and start Node Manager after the variable has been set in the shell.

8.9.3.12.4 Setting Environment and Superuser Privi leges for the wlsifconfig.sh Script

The fourth step is to set environment and superuser privileges for the wlsifconfig.sh script:

Ensure that your PATH environment variable includes these files:

Table 8-9 Files Required for the PATH Environment Variable

File Located in this directory

wlsifconfig.sh

DOMAIN_HOME/bin/server_migration

wlscontrol.sh

WL_HOME/common/bin

nodemanager.domains

WL_HOME/common
Grant sudo configuration for the wlsifconfig.sh script.
- Configure sudo to work without a password prompt.
- For security reasons, sudo should be restricted to the subset of commands required to run the wlsifconfig.sh script. For example, perform the following steps to set the environment and superuser privileges for the wlsifconfig.sh script:
- Grant sudo privilege to the WebLogic user ('oracle') with no password restriction, and grant execute privilege on the /sbin/ifconfig and /sbin/arping binaries.
- Make sure the script is executable by the WebLogic user ('oracle'). The following is an example of an entry inside /etc/sudoers granting sudo execution privilege for oracle and also over ifconfig and arping:
```
oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping
```
Note:
Ask the system administrator for the sudo and system rights as appropriate to this step.

File	Located in this directory
wlsifconfig.sh	DOMAIN_HOME/bin/server_migration
wlscontrol.sh	WL_HOME/common/bin
nodemanager.domains	WL_HOME/common

8.9.3.12.5 Configuring Server Migration Tar gets

The fifth step is to configure server migration targets. You first assign all the available nodes for the cluster's members and then specify candidate machines (in order of preference) for each server that is configured with server migration. Follow these steps to configure cluster migration in a migration in a cluster:

Log into the Oracle WebLogic Server Administration Console at http://oimhost1.mycompany.com:7001/console using the Admin credentials.
In the Domain Structure window, expand Environment and select Clusters. The Summary of Clusters page is displayed.
Click the cluster for which you want to configure migration (OIM_CLUSTER) in the Name column of the table.
Click the Migration tab.
Click Lock and Edit.
In the Available field, select the machine to which to allow migration and click the right arrow. In this case, select OIMHOST1 and OIMHOST2.
Select the data source to be used for automatic migration. In this case, select the leasing data source.
Click Save.
Click Activate Changes.
Set the candidate machines for server migration. You must perform this task for all of the managed servers as follows:
1. In the Domain Structure window of the Oracle WebLogic Server Administration Console, expand Environment and select Servers.
  
  Tip:
  Click Customize this table in the Summary of Servers page and move Current Machine from the Available window to the Chosen window to view the machine on which the server is running. This will be different from the configuration if the server gets migrated automatically.
2. Select the server for which you want to configure migration.
3. Click the Migration tab.
4. In the Available field, located in the Migration Configuration section, select the machines to which to allow migration and click the right arrow. For WLS_OIM1, select OIMHOST2. For WLS_OIM2, select OIMHOST1.
5. Select Automatic Server Migration Enabled. This enables Node Manager to start a failed server on the target node automatically.
6. Click Save.
7. Click Activate Changes.
8. Repeat the steps above for the WLS_SOA1 and WLS_SOA2 managed servers.
9. Restart the administration server, Node Managers, and the servers for which server migration has been configured.

8.9.3.12.6 Testing the Server Migr ation

The final step is to test the server migration. Perform these steps to verify that server migration is working properly:

From OIMHOST1:

Stop the WLS_OIM1 managed server. To do this, run this command:
```
OIMHOST1> kill -9 pid
```
where pid specifies the process ID of the managed server. You can identify the pid in the node by running this command:
```
OIMHOST1> ps -ef | grep WLS_OIM1
```
Watch the Node Manager console. You should see a message indicating that WLS_OIM1's floating IP has been disabled.
Wait for Node Manager to try a second restart of WLS_OIM1. It waits for a fence period of 30 seconds before trying this restart.
Once Node Manager restarts the server, stop it again. Node Manager should now log a message indicating that the server will not be restarted again locally.

From OIMHOST2:

Watch the local Node Manager console. After 30 seconds since the last try to restart WLS_OIM1 on OIMHOST1, Node Manager on OIMHOST2 should prompt that the floating IP for WLS_OIM1 is being brought up and that the server is being restarted in this node.
Access the soa-infra console in the same IP.

Follow the steps above to test server migration for the WLS_OIM2, WLS_SOA1, and WLS_SOA2 managed servers.

Table 8-10 shows the managed servers and the hosts they migrate to in case of a failure.

Table 8-10 WLS_OIM1, WLS_OIM2, WLS_SOA1, WLS_SOA2 Server Migration

Managed Server	Migrated From	Migrated To
WLS_OIM1	OIMHOST1	OIMHOST2
WLS_OIM2	OIMHOST2	OIMHOST1
WLS_SOA1	OIMHOST1	OIMHOST2
WLS_SOA2	OIMHOST2	OIMHOST1

Verification From the Administration Console

Migration can also be verified in the Administration Console:

Log into the Oracle WebLogic Server Administration Console at http://oimhost1.mycompany.com:7001/console using the Admin credentials.
Click Domain on the left console.
Click the Monitoring tab and then the Migration sub tab.

The Migration Status table provides information on the status of the migration.

Note:

After a server is migrated, to fail it back to its original node/machine, stop the managed server from the Oracle WebLogic Administration Console and then start it again. The appropriate Node Manager will start the managed server on the machine to which it was originally assigned.

8.9.3.13 Configuring a Shared JMS Persistence Store

Configure the location for all of the persistence stores as a shared directory that is visible from both OIMHOST1 and OIMHOST2. As JMS messages are persisted in the file system for each server's local file system, shared storage is necessary for the JMS persistence store for WebLogic server migration. Without shared storage, a migrated server will not have access to the pending JMS messages. You must change all of the persistent stores to use a shared base directory as follows:

Log into the Oracle WebLogic Server Administration Console at http://oimhost1.mycompany.com:7001/console using the Admin credentials.
In the Domain Structure window, expand the Services node and then click the Persistence Stores node. The Summary of Persistence Stores page is displayed.
Select the persistence store (represented as a hyperlink) from the Name column of the table. The Settings page for the persistence store is displayed.
On the Configuration tab, in the Directory field, enter the location of a persistent storage solution (such as NAS or SAN) that is available to other servers in the cluster. Specifying this location enables pending JMS messages to be sent.
The location should follow this directory structure:
- For the WLS_SOA1 and WLS_SOA2 servers, use a directory structure similar to:
```
ORACLE_BASE/admin/domainName/soaClusterName/jms
```
- For the WLS_OIM1 and WLS_OIM2 servers, use a directory structure similar to:
```
ORACLE_BASE/admin/domainName/oimClusterName/jms
```
  Note:
  The WLS_OIM1 and WLS_OIM2 servers must be able to access this directory.
  The WLS_SOA1 and WLS_SOA2 servers must be able to access this directory.
  
  This directory must exist before you restart the server.
Click Save and Activate.
Restart the servers to make the change in the persistent stores take effect.

8.9.3.14 Configuring a Default Persistence Store for Transaction Recovery

Each Oracle WebLogic Managed Server has a transaction log that stores information about inflight transactions that are coordinated by the server that may not have been completed. The WebLogic Server uses this transaction log for recovery from system crashes or network failures. To leverage the migration capability of the Transaction Recovery Service for the servers within a cluster, store the transaction log in a location accessible to all the servers in the cluster. Without shared storage, other servers in the cluster cannot do a transaction recovery in the case of a server failure, so the operation may need to be retried.

Note:

Preferably, this location should be a dual-ported SCSI disk or on a Storage Area Network (SAN).

Perform these steps to set the location for the default persistence stores for the Oracle Identity Manager and SOA Servers:

Log into the Oracle WebLogic Server Administration Console at http://oimhost1.mycompany.com:7001/console using the Admin credentials.
In the Domain Structure window, expand the Environment node and then click the Servers node. The Summary of Servers page is displayed.
Select the name of the server (represented as a hyperlink) in the Name column of the table. The Settings page for the selected server is displayed, and it defaults to the Configuration tab.
Click the Services tab.
In the Default Store section of the page, enter the path to the folder where the default persistent stores will store their data files. The directory structure of the path should be:
- For the WLS_SOA1 and WLS_SOA2 servers, use a directory structure similar to:
```
ORACLE_BASE/admin/domainName/soaClusterName/tlogs
```
- For the WLS_OIM1 and WLS_OIM2 servers, use a directory structure similar to:
```
ORACLE_BASE/admin/domainName/oimClusterName/tlogs
```
Click Save.

Note:
To enable migration of the Transaction Recovery Service, specify a location on a persistent storage solution that is available to the managed servers in the cluster. WLS_SOA1, WLS_SOA2, WLS_OIM1, and WLS_OIM2 must be able to access this directory.

8.9.3.15 Install Oracle HTTP Server on WEBHOST1 and WEBHOST2

For instructions on installing Oracle HTTP Server on WEBHOST1 and WEBHOST2, see Section 8.5.3.5.1, "Installing Oracle HTTP Server for the Web Tier."

8.9.3.16 Configuring Oracle Identity Manager to Work with the Web Tier

This section describes how to configure Oracle Identity Manager to work with the Oracle Web Tier.

8.9.3.16.1 Prerequisites

Verify that the following tasks have been performed:

Oracle Web Tier has been installed on WEBHOST1 and WEBHOST2.
Oracle Identity Manager has been installed and configured on OIMHOST1 and OIMHOST2.
The load balancer has been configured with a virtual hostname (sso.mycompany.com) pointing to the webservers on WEBHOST1 and WEBHOST2.
The load balancer has been configured with a virtual hostname (oiminternal.mycompany.com) pointing to webservers WEBHOST1 and WEBHOST2.
For details on configuring the VIPs on the load balancer, see Section 8.2.5.4, "Configuring Virtual Server Names and Ports for the Load Balancer."

8.9.3.16.2 Configuring Oracle HTTP Servers to Front End the OIM and SOA Managed Servers

On each of the web servers on WEBHOST1 and WEBHOST2, create a file called oim.conf in the directory ORACLE_INSTANCE/config/OHS/component/moduleconf. This file must contain the following information:

# oim admin console(idmshell based)
   <Location /admin>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid
    WebLogicCluster oimvhn1.mycompany.com:14000,oimvhn2.mycompany.com:14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
    WLProxySSL ON
    WLProxySSLPassThrough ON
   </Location>
 
# oim self and advanced admin webapp consoles(canonic webapp)
 
  <Location /oim>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid
    WebLogicCluster oimvhn1.mycompany.com:14000,oimvhn2.mycompany.com:14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
    WLProxySSL ON
    WLProxySSLPassThrough ON
   </Location>

# SOA Callback webservice for SOD - Provide the SOA Managed Server Ports
  <Location /sodcheck>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid
    WebLogicCluster oimvhn1.mycompany.com:8001,oimvhn2.mycompany.com:8001
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
    WLProxySSL ON
    WLProxySSLPassThrough ON
   </Location>

# Callback webservice for SOA. SOA calls this when a request is approved/rejected
# Provide the SOA Managed Server Port
  <Location /workflowservice>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid
    WebLogicCluster oimvhn1.mycompany.com:14000,oimvhn2.mycompany.com:14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
    WLProxySSL ON
    WLProxySSLPassThrough ON
  </Location>

# xlWebApp - Legacy 9.x webapp (struts based)
   <Location /xlWebApp>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid
    WebLogicCluster oimvhn1.mycompany.com:14000,oimvhn2.mycompany.com:14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
    WLProxySSL ON
    WLProxySSLPassThrough ON
  </Location>

# Nexaweb WebApp - used for workflow designer and DM
  <Location /Nexaweb>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid
    WebLogicCluster oimvhn1.mycompany.com:14000,oimvhn2.mycompany.com:14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
    WLProxySSL ON
    WLProxySSLPassThrough ON
  </Location>

# used for FA Callback service.
  <Location /callbackResponseService>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid
    WebLogicCluster oimvhn1.mycompany.com:14000,oimvhn2.mycompany.com:14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
    WLProxySSL ON
    WLProxySSLPassThrough ON
  </Location>

# spml xsd profile
  <Location /spml-xsd>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid
    WebLogicCluster oimvhn1.mycompany.com:14000,oimvhn2.mycompany.com:14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
    WLProxySSL ON
    WLProxySSLPassThrough ON
  </Location>

  <Location /HTTPClnt>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid
    WebLogicCluster oimvhn1.mycompany.com:14000,oimvhn2.mycompany.com:14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
    WLProxySSL ON
    WLProxySSLPassThrough ON
  </Location>

Create a file called virtual_hosts.conf in ORACLE_INSTANCE/config/OHS/component/moduleconf. The file must contain the following information:

NameVirtualHost *:7777
<VirtualHost *:7777>

  ServerName http://sso.mycompany.com:7777
  RewriteEngine On
  RewriteOptions inherit
  UseCanonicalName On
  </VirtualHost>

<VirtualHost *:7777>
  ServerName http://oiminternal.mycompany.com:80
  RewriteEngine On
  RewriteOptions inherit
  UseCanonicalName On
</VirtualHost>

Save the file on both WEBHOST1 and WEBHOST2.
Stop and start the Oracle HTTP Server instances on both WEBHOST1 and WEBHOST2 as described in Section 8.14, "Starting and Stopping Oracle Identity Management Components."

8.9.3.17 Validate the Oracle HTTP Server Configuration

To validate that Oracle HTTP Server is configured properly, follow these steps:

In a web browser, enter the following URL for the Oracle Identity Manager Console:
```
http://sso.mycompany.com:7777/oim
```
The Oracle Identity Manager Console login page should display.
Log into the Oracle Identity Manager Console using the credentials for the xelsysadm user.

8.9.3.18 Oracle Identity Manager Failover and Expected Behavior

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 a high availability environment, a hardware load balancer is used to load balance requests between the multiple Oracle Identity Manager instances. If one of the Oracle Identity Manager instances fails, the load balancer detects the failure and routes requests to the surviving instances.

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

The surviving Oracle Identity Manager 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 Manager 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.

Be aware of the following when you deploy Oracle Identity Manager in a high availability configuration:

Oracle Identity Manager can be deployed on an Oracle RAC database, but Oracle RAC failover is not transparent for Oracle Identity Manager in this release. If an Oracle RAC failover occurs, end users may have to resubmit their requests.
Oracle Identity Manager always requires that at least one of the nodes in the SOA cluster be available. If the SOA cluster is not available, end user requests will fail. Oracle Identity Manager does not retry for a failed SOA call. Therefore, the end user must retry when a SOA call fails.

8.9.3.19 Troubleshooting Oracle Identity Manager High Availability

If you are creating a user in Oracle Identity Manager (by logging into Oracle Identity Manager, clicking the Administration tab, clicking the Create User link, entering the required information in the fields, and clicking Save) in an active-active Oracle Identity Manager configuration, and the Oracle Identity Manager server that is handling the request fails, you may see a "ResourceConnectionValidationxception" in the Oracle Identity Manager log file, similar to:

[2010-06-14T15:14:48.738-07:00] [oim_server2] [ERROR] [] [XELLERATE.SERVER]
[tid: [ACTIVE].ExecuteThread: '0' for queue: 'weblogic.kernel.Default
(self-tuning)'] [userId: xelsysadm] [ecid:
004YGJGmYrtEkJV6u3M6UH00073A0005EI,0:1] [APP: oim#11.1.1.3.0] [dcid:
12eb0f9c6e8796f4:-785b18b3:12938857792:-7ffd-0000000000000037] [URI:
/admin/faces/pages/Admin.jspx] Class/Method:
PooledResourceConnection/heartbeat encounter some problems: Operation timed
out[[
com.oracle.oim.gcp.exceptions.ResourceConnectionValidationxception: Operation
timed out
        at
oracle.iam.ldapsync.impl.repository.LDAPConnection.heartbeat(LDAPConnection.ja
va:162)
        at
com.oracle.oim.gcp.ucp.PooledResourceConnection.heartbeat(PooledResourceConnec
tion.java:52)
         .
         .
         .

Although this exception is received, the user is created fine.

8.9.3.20 Scaling Up and Scaling Out the Oracle Identity Manager Topology

You can scale out or scale up the Oracle Identity Manager high availability topology. When you scale up the topology, you add new managed servers to nodes that are already running one or more managed servers. When you scale out the topology, you add new managed servers to new nodes.

8.9.3.20.1 Scaling Up Oracle Identity Manager

In this case, you already have a node that runs a managed server configured with SOA components. The node contains a Middleware home, an Oracle HOME (SOA) and a domain directory for existing managed servers.

You can use the existing installations (the Middleware home, and domain directories) for creating new WLS_OIM and WLS_SOA servers. There is no need to install the OIM and SOA binaries in a new location, or to run pack and unpack.

Follow these steps for scaling up the topology:

Using the Administration Console, clone either the WLS_OIM1 or the WLS_SOA1 into a new managed server. The source managed server to clone should be one that already exists on the node where you want to run the new managed server.

To clone a managed server:
1. Select Environment -> Servers from the Administration Console.
2. Select the managed server that you want to clone (for example, WLS_OIM1 or WLS_SOA1).
3. Select Clone.
4. Name the new managed server WLS_OIMn or WLS_SOAn, where n is a number to identity the new managed server.
The rest of the steps assume that you are adding a new server to OIMHOST1, which is already running WLS_SOA1 and WLS_OIM1.
For the listen address, assign the host name or IP to use for this new managed server. If you are planning to use server migration as recommended for this server, this should be the VIP (also called a floating IP) to enable it to move to another node. The VIP should be different from the one used by the managed server that is already running.
Create JMS Servers for SOA, OIM and UMS on the new managed server.
1. Use the Oracle WebLogic Server Administration Console to create a new persistent store for the new SOAJMSServer and name it, for example, SOAJMSFileStore_n. Specify the path for the store. This should be a directory on shared storage.
```
ORACLE_BASE/admin/domain_name/cluster_name/jms/SOAJMSFileStore_n
```
  Note:
  This directory must exist before the managed server is started or the start operation fails.
2. Create a new JMS Server for SOA, for example, SOAJMSServer_n. Use the SOAJMSFileStore_n for this JMSServer. Target the SOAJMSServer_n Server to the recently created Managed Server (WLS_SOAn).
3. Create a new persistence store for the new UMSJMSServer, for example, UMSJMSFileStore_n Specify the path for the store. This should be a directory on shared storage.
```
ORACLE_BASE/admin/domain_name/cluster_name/jms/UMSJMSFileStore_n
```
  Note:
  This directory must exist before the managed server is started or the start operation fails.
  You can also assign SOAJMSFileStore_n as store for the new UMS JMS Servers. For the purpose of clarity and isolation, individual persistent stores are used in the following steps.
4. Create a new JMS Server for UMS, for example, UMSJMSServer_n. Use the UMSJMSFileStore_n for this JMSServer. Target the UMSJMSServer_n Server to the recently created managed server (WLS_SOAn).
5. Create a new persistence store for the new OIMJMSServer, for example, OIMJMSFileStore_n. Specify the path for the store. This should be a directory on shared storage.
```
ORACLE_BASE/admin/domain_name/cluster_name/jms/OIMJMSFileStore_n
```
  Note:
  This directory must exist before the managed server is started or the start operation fails.
  You can also assign SOAJMSFileStore_n as store for the new OIM JMS Servers. For the purpose of clarity and isolation, individual persistent stores are used in the following steps.
6. Create a new JMS Server for OIM, for example, OIMJMSServer_n. Use the OIMJMSFileStore_n for this JMSServer. Target the OIMJMSServer_n Server to the recently created Managed Server (WLS_OIMn).
7. Update the SubDeployment targets for the SOA JMS Module to include the recently created SOA JMS Server. To do this, expand the Services node and then expand the Messaging node. Choose JMS Modules from the Domain Structure window of the Oracle WebLogic Server Administration Console. The JMS Modules page appears. Click SOAJMSModule (represented as a hyperlink in the Names column of the table). The Settings page for SOAJMSModule appears. Click the SubDeployments tab. The subdeployment module for SOAJMS appears.
  
  Note:
  This subdeployment module name is a random name in the form of SOAJMSServerXXXXXX resulting from the Config Wizard JMS configuration for the first two servers (WLS_SOA1 and WLS_SOA2).
8. Click the SOAJMSServerXXXXXX subdeployment. Add the new JMS Server for SOA called SOAJMSServer_n to this subdeployment. Click Save.
9. Update the SubDeployment targets for the UMSJMSSystemResource to include the recently created UMS JMS Server. To do this, expand the Services node and then expand the Messaging node. Choose JMS Modules from the Domain Structure window of the Oracle WebLogic Server Administration Console. The JMS Modules page appears. Click UMSJMSSystemResource (represented as a hyperlink in the Names column of the table). The Settings page for UMSJMSSystemResource appears. Click the SubDeployments tab. The subdeployment module for UMSJMS appears.
  
  Note:
  This subdeployment module name is a random name in the form of UCMJMSServerXXXXXX resulting from the Config Wizard JMS configuration for the first two servers (WLS_SOA1 and WLS_SOA2).
10. Click the UMSJMSServerXXXXXX subdeployment. Add the new JMS Server for UMS called UMSJMSServer_n to this subdeployment. Click Save.
11. Update the SubDeployment targets for OIMJMSModule to include the recently created OIM JMS Server. To do this, expand the Services node and then expand the Messaging node. Choose JMS Modules from the Domain Structure window of the Oracle WebLogic Server Administration Console. The JMS Modules page appears. Click OIMJMSSystemResource (represented as a hyperlink in the Names column of the table). The Settings page for OIMJMSSystemResource appears. Click the SubDeployments tab. The subdeployment module for OIMJMS appears.
  
  Note:
  This subdeployment module name is a random name in the form of OIMJMSServerXXXXXX resulting from the Config Wizard JMS configuration for the first two servers (WLS_OIM1 and WLS_OIM2).
12. Click the OIMMSServerXXXXXX subdeployment. Add the new JMS Server for OIM called OIMJMSServer_n to this subdeployment. Click Save.
Configure Oracle Coherence for deploying composites, as described inSection 5.13.8, "Configuring Oracle Coherence for Deploying Composites."

Note:
Only the localhost field needs to be changed for the server. Replace the localhost with the listen address of the new server added, for example:
Dtangosol.coherence.localhost=SOAHOST1VHNn
Configure the transaction persistent store for the new server. This should be a shared storage location visible from other nodes.

From the Administration Console, select Server_name > Services tab. Under Default Store, in Directory, enter the path to the folder where you want the default persistent store to store its data files.
Disable host name verification for the new managed server. Before starting and verifying the WLS_SOAn managed server, you must disable host name verification. You can re-enable it after you have configured server certificates for the communication between the Oracle WebLogic Administration Server and the Node Manager in SOAHOSTn. If the source server from which the new one has been cloned had already disabled hostname verification, these steps are not required (the hostname verification settings is propagated to the cloned server).

To disable host name verification:
1. In the Oracle Enterprise Manager Console, select Oracle WebLogic Server Administration Console.
2. Expand the Environment node in the Domain Structure window.
3. Click Servers. The Summary of Servers page appears.
4. Select WLS_SOAn in the Names column of the table. The Settings page for the server appears.
5. Click the SSL tab.
6. Click Advanced.
7. Set Hostname Verification to None.
8. Click Save.
Start and test the new managed server from the Administration Console.
1. Shut down the existing managed servers in the cluster.
2. Ensure that the newly created managed server, WLS_SOAn, is up.
3. Access the application on the newly created managed server (http://vip:port/soa-infra). The application should be functional
Configure Server Migration for the new managed server.

Note:
Since this is a scale up operation, the node should already contain a Node Manager and environment configured for server migration. The floating IP for the new SOA managed server should also be already present.

Configure server migration by following these steps:
1. Log into the Administration Console.
2. In the left pane, expand Environment and select Servers.
3. Select the server (represented as a hyperlink) for which you want to configure migration. The Settings page for that server appears.
4. Click the Migration tab.
5. In the Available field, in the Migration Configuration section, select the machines to which to allow migration and click the right arrow. Select the same migration targets as for the servers that already exist on the node.
  
  For example, for new managed servers on SOAHOST1, which is already running WLS_SOA1, select SOAHOST2. For new managed servers on SOAHOST2, which is already running WLS_SOA2, select SOAHOST1.
  
  Make sure the appropriate resources are available to run the managed servers concurrently during migration.
6. Select the Automatic Server Migration Enabled option. This enables the Node Manager to start a failed server on the target node automatically.
7. Click Save.
8. Restart the Administration Server, managed servers, and Node Manager.
9. Repeat the steps in this list for configuring server migration for the newly created WLS_OIMn managed server.
Test server migration for this new server. Follow these steps from the node where you added the new server:
1. Stop the WLS_SOAn managed server.
  
  To do this, run "kill -9 pid" on the PID of the managed server. You can identify the PID of the node using "ps -ef | grep WLS_SOAn".
2. Watch the Node Manager Console: you should see a message indicating that WLS_SOA1's floating IP has been disabled.
3. Wait for the Node Manager to try a second restart of WLS_SOAn. Node Manager waits for a fence period of 30 seconds before trying this restart.
4. Once Node Manager restarts the server, stop it again. Now Node Manager should log a message indicating that the server will not be restarted again locally.

8.9.3.20.2 Scaling Out Oracle Identity Manager

When you scale out the topology, you add new managed servers configured with SOA to new nodes.

Before performing the steps in this section, check that you meet these requirements:

There must be existing nodes running managed servers configured with SOA within the topology.
The new node can access the existing home directories for WebLogic Server and SOA. (Use the existing installations in shared storage for creating a new WLS_SOA or WLS_WSM managed server. You do not need to install WebLogic Server or SOA binaries in a new location but you do need to run pack and unpack to bootstrap the domain configuration in the new node.)

Note:
If there is no existing installation in shared storage, installing WebLogic Server and SOA in the new nodes is required as described in Section 5.13, "Configuring High Availability for Oracle SOA Service Infrastructure and Component Service Engines."

Note:
When an ORACLE_HOME or WL_HOME is shared by multiple servers in different nodes, Oracle recommends keeping the Oracle Inventory and Middleware home list in those nodes updated for consistency in the installations and application of patches. To update the oraInventory in a node and "attach" an installation in a shared storage to it, use ORACLE_HOME/oui/bin/attachHome.sh. To update the Middleware home list to add or remove a WL_HOME, edit the user_home/bea/beahomelist file. See the following steps.

Follow these steps for scaling out the topology:

On the new node, mount the existing Middleware home, which should include the SOA installation and the domain directory, and ensure that the new node has access to this directory, just like the rest of the nodes in the domain.
To attach ORACLE_HOME in shared storage to the local Oracle Inventory, execute the following commands:
```
SOAHOSTn>cd ORACLE_BASE/product/fmw/soa/
SOAHOSTn>./attachHome.sh -jreLoc ORACLE_BASE/fmw/jrockit_160_17_R28.0.0-655
```
To update the Middleware home list, create (or edit, if another WebLogic installation exists in the node) the MW_HOME/bea/beahomelist file and add ORACLE_BASE/product/fmw to it.
Log in to the Oracle WebLogic Administration Console.
Create a new machine for the new node that will be used, and add the machine to the domain.
Update the machine's Node Manager's address to map the IP of the node that is being used for scale out.
Use the Oracle WebLogic Server Administration Console to clone WLS_SOA1 into a new managed server. Name it WLS_SOAn, where n is a number.

Note:
These steps assume that you are adding a new server to node n, where no managed server was running previously.
Assign the host name or IP to use for the new managed server for the listen address of the managed server.

If you are planning to use server migration for this server (which Oracle recommends), this should be the VIP (also called a floating IP) for the server. This VIP should be different from the one used for the existing managed server.
Create JMS servers for SOA, OIM (if applicable), and UMS on the new managed server.
1. Use the Oracle WebLogic Server Administration Console to create a new persistent store for the new SOAJMSServer and name it, for example, SOAJMSFileStore_n. Specify the path for the store. This should be a directory on shared storage.
```
ORACLE_BASE/admin/domain_name/cluster_name/jms/SOAJMSFileStore_n
```
  Note:
  This directory must exist before the managed server is started or the start operation fails.
2. Create a new JMS Server for SOA, for example, SOAJMSServer_n. Use the SOAJMSFileStore_n for this JMSServer. Target the SOAJMSServer_n Server to the recently created Managed Server (WLS_SOAn).
3. Create a new persistence store for the new UMSJMSServer, for example, UMSJMSFileStore_n Specify the path for the store. This should be a directory on shared storage.
```
ORACLE_BASE/admin/domain_name/cluster_name/jms/UMSJMSFileStore_n
```
  Note:
  This directory must exist before the managed server is started or the start operation fails.
  You can also assign SOAJMSFileStore_n as store for the new UMS JMS Servers. For the purpose of clarity and isolation, individual persistent stores are used in the following steps.
4. Create a new JMS Server for UMS, for example, UMSJMSServer_n. Use the UMSJMSFileStore_n for this JMSServer. Target the UMSJMSServer_n Server to the recently created managed server (WLS_SOAn).
5. Create a new persistence store for the new OIMJMSServer, for example, OIMJMSFileStore_n. Specify the path for the store. This should be a directory on shared storage.
```
ORACLE_BASE/admin/domain_name/cluster_name/jms/OIMJMSFileStore_n
```
  Note:
  This directory must exist before the managed server is started or the start operation fails.
  You can also assign SOAJMSFileStore_n as store for the new OIM JMS Servers. For the purpose of clarity and isolation, individual persistent stores are used in the following steps.
6. Create a new JMS Server for OIM, for example, OIMJMSServer_n. Use the OIMJMSFileStore_n for this JMSServer. Target the OIMJMSServer_n Server to the recently created Managed Server (WLS_OIMn).
7. Update the SubDeployment targets for the SOA JMS Module to include the recently created SOA JMS Server. To do this, expand the Services node and then expand the Messaging node. Choose JMS Modules from the Domain Structure window of the Oracle WebLogic Server Administration Console. The JMS Modules page appears. Click SOAJMSModule (represented as a hyperlink in the Names column of the table). The Settings page for SOAJMSModule appears. Click the SubDeployments tab. The subdeployment module for SOAJMS appears.
  
  Note:
  This subdeployment module name is a random name in the form of SOAJMSServerXXXXXX resulting from the Config Wizard JMS configuration for the first two servers (WLS_SOA1 and WLS_SOA2).
8. Click the SOAJMSServerXXXXXX subdeployment. Add the new JMS Server for SOA called SOAJMSServer_n to this subdeployment. Click Save.
9. Update the SubDeployment targets for the UMSJMSSystemResource to include the recently created UMS JMS Server. To do this, expand the Services node and then expand the Messaging node. Choose JMS Modules from the Domain Structure window of the Oracle WebLogic Server Administration Console. The JMS Modules page appears. Click UMSJMSSystemResource (represented as a hyperlink in the Names column of the table). The Settings page for UMSJMSSystemResource appears. Click the SubDeployments tab. The subdeployment module for UMSJMS appears.
  
  Note:
  This subdeployment module name is a random name in the form of UCMJMSServerXXXXXX resulting from the Config Wizard JMS configuration for the first two servers (WLS_SOA1 and WLS_SOA2).
10. Click the UMSJMSServerXXXXXX subdeployment. Add the new JMS Server for UMS called UMSJMSServer_n to this subdeployment. Click Save.
11. Update the SubDeployment targets for OIMJMSModule to include the recently created OIM JMS Server. To do this, expand the Services node and then expand the Messaging node. Choose JMS Modules from the Domain Structure window of the Oracle WebLogic Server Administration Console. The JMS Modules page appears. Click OIMJMSSystemResource (represented as a hyperlink in the Names column of the table). The Settings page for OIMJMSSystemResource appears. Click the SubDeployments tab. The subdeployment module for OIMJMS appears.
  
  Note:
  This subdeployment module name is a random name in the form of OIMJMSServerXXXXXX resulting from the Config Wizard JMS configuration for the first two servers (WLS_OIM1 and WLS_OIM2).
12. Click the OIMMSServerXXXXXX subdeployment. Add the new JMS Server for OIM called OIMJMSServer_n to this subdeployment. Click Save.

Run the pack command on SOAHOST1 to create a template pack as follows:

SOAHOST1> cd ORACLE_COMMON_HOME/common/bin
SOAHOST1> ./pack.sh -managed=true/
-domain=MW_HOME/user_projects/domains/soadomain/
-template=soadomaintemplateScale.jar -template_name=soa_domain_templateScale

Run the following command on SOAHOST1 to copy the template file created to SOAHOSTn:

SOAHOST1> scp soadomaintemplateScale.jar oracle@SOAHOSTN:/
ORACLE_BASE/product/fmw/soa/common/bin

Run the unpack command on SOAHOSTn to unpack the template in the managed server domain directory as follows:

SOAHOSTn> cd ORACLE_BASE/product/fmw/soa/common/bin
SOAHOSTN> ./unpack.sh /
-domain=ORACLE_BASE/product/fmw/user_projects/domains/soadomain/
-template=soadomaintemplateScale.jar

Configure Oracle Coherence for deploying composites, as described in Section 5.13.8, "Configuring Oracle Coherence for Deploying Composites."

Note:
Only the localhost field needs to be changed for the server. Replace the localhost with the listen address of the new server added, for example:
Dtangosol.coherence.localhost=SOAHOST1VHNn
Configure the transaction persistent store for the new server. This should be a shared storage location visible from other nodes.

From the Administration Console, select Server_name > Services tab. Under Default Store, in Directory, enter the path to the folder where you want the default persistent store to store its data files.
Disable host name verification for the new managed server. Before starting and verifying the WLS_SOAn managed server, you must disable host name verification. You can re-enable it after you have configured server certificates for the communication between the Oracle WebLogic Administration Server and the Node Manager in SOAHOSTn. If the source server from which the new one has been cloned had already disabled hostname verification, these steps are not required (the hostname verification settings is propagated to the cloned server).

To disable host name verification:
1. In the Oracle Enterprise Manager Console, select Oracle WebLogic Server Administration Console.
2. Expand the Environment node in the Domain Structure window.
3. Click Servers. The Summary of Servers page appears.
4. Select WLS_SOAn in the Names column of the table. The Settings page for the server appears.
5. Click the SSL tab.
6. Click Advanced.
7. Set Hostname Verification to None.
8. Click Save.
Start the Node Manager on the new node. To start the Node Manager, use the installation in shared storage from the existing nodes, and start Node Manager by passing the host name of the new node as a parameter as follows:
```
SOAHOSTn> WL_HOME/server/bin/startNodeManager new_node_ip
```
Start and test the new managed server from the Administration Console.
1. Shut down the existing managed servers in the cluster.
2. Ensure that the newly created managed server, WLS_SOAn, is up.
3. Access the application on the newly created managed server (http://vip:port/soa-infra). The application should be functional
Configure Server Migration for the new managed server.

Note:
Since this new node is using an existing shared storage installation, the node is already using a Node Manager and environment configured for server migration that includes netmask, interface, wlsifconfig script superuser privileges. The floating IP for the new SOA managed server is already present in the new node.

Configure server migration by following these steps:
1. Log into the Administration Console.
2. In the left pane, expand Environment and select Servers.
3. Select the server (represented as a hyperlink) for which you want to configure migration. The Settings page for that server appears.
4. Click the Migration tab.
5. In the Available field, in the Migration Configuration section, select the machines to which to allow migration and click the right arrow.
  
  Note:
  Specify the least-loaded machine as the migration target for the new server. The required capacity planning must be completed so that this node has enough available resources to sustain an additional managed server.
6. Select the Automatic Server Migration Enabled option. This enables the Node Manager to start a failed server on the target node automatically.
7. Click Save.
8. Restart the Administration Server, managed servers, and Node Manager.
Test server migration for this new server. Follow these steps from the node where you added the new server:
1. Stop the WLS_SOAn managed server.
  
  To do this, run "kill -9 pid" on the PID of the managed server. You can identify the PID of the node using "ps -ef | grep WLS_SOAn".
2. Watch the Node Manager Console: you should see a message indicating that WLS_SOA1's floating IP has been disabled.
3. Wait for the Node Manager to try a second restart of WLS_SOAn. Node Manager waits for a fence period of 30 seconds before trying this restart.
4. Once Node Manager restarts the server, stop it again. Now Node Manager should log a message indicating that the server will not be restarted again locally.

8.10 Authorization Policy Manager High Availability

This section provides an introduction to Authorization Policy Manager 11gR1 and describes how to design and deploy a high availability environment for Authorization Policy Manager.

To use Authorization Policy Manager in a high availability active-passive Cold Failover Cluster, follow the instructions for setting up WebLogic Server in an active-passive Cold Failover Cluster in Section 12.2.2.3, "Transforming the Administration Server for Cold Failover Cluster."

Authorization Policy Manager is not used in high availability active-active deployments because it is deployed to the WebLogic Administration Server JVM.

Authorization Policy Manager is a graphical interface tool for administering application policies.

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

Authorization Policy Manager requires that:

The domain policy store be LDAP-based; the supported policy store is Oracle Internet Directory.
The domain identity store be LDAP-based; the supported identity store types are Oracle Internet Directory, Oracle Virtual Directory, Oracle WebLogic Server Embedded LDAP, Sun Java System Directory Service version 6.3, Active Directory 2003 and 2008, Novell eDirectory 8.8, and OpenLDAP 2.2 and 2.4.
Two particular data sources be set: mds-ApplicationMDSDB and apm-DBDS. These data sources can be configured with the WebLogic Console (under JDBC > Data Sources).

For more information about using Authorization Policy Manager, see Oracle Fusion Middleware Administrator's Guide for Authorization Policy Manager.

8.11 Oracle Identity Navigator High Availability

Oracle Identity Management Navigator is an administrative portal designed to act as a launch pad for Oracle Identity Management products. It does not replace the individual product consoles. Rather, it allows you to access the Oracle Identity Management consoles from one site. For more details on Oracle Identity Management Navigator, refer to Oracle Fusion Middleware Administrator's Guide for Oracle Identity Management Navigator.

Oracle Identity Navigator is not used in high availability active-active deployments because it is deployed to the WebLogic Administration Server JVM.

To use Oracle Identity Navigator in a high availability active-passive Cold Failover Cluster, follow the instructions for setting up WebLogic Server in an active-passive Cold Failover Cluster in Section 12.2.2.3, "Transforming the Administration Server for Cold Failover Cluster."

8.12 Oracle Adaptive Access Manager High Availability

This section provides an introduction to Oracle Adaptive Access Manager and describes how to design and deploy a high availability environment for Oracle Adaptive Access Manager.

Oracle Adaptive Access Manager is built on a J2EE-based, multi-tier deployment architecture that separates the platform's presentation, business logic, and data tiers. Because of this separation of tiers, Oracle Adaptive Access Manager can rapidly scale with the performance needs of the customer. The architecture can leverage the most flexible and supported cross-platform J2EE services available: a combination of Java, XML and object technologies. This architecture makes Oracle Adaptive Access Manager a scalable, fault-tolerant solution.

This section includes the following topics:

Section 8.12.1, "Oracle Adaptive Access Manager Component Architecture"
Section 8.12.2, "Oracle Adaptive Access Manager High Availability Concepts"
Section 8.12.3, "Oracle Adaptive Access Manager High Availability Configuration Steps"

8.12.1 Oracle Adaptive Access Manager Component Architecture

Figure 8-16 shows the single instance architecture for Oracle Adaptive Access Manager.

Figure 8-16 Oracle Adaptive Access Manager Single Instance Architecture

Description of "Figure 8-16 Oracle Adaptive Access Manager Single Instance Architecture"

In the Oracle Adaptive Access Manager single instance architecture shown in Figure 8-16, end users access customer web applications, which communicate with the OAAM Server application and its policies using SOAP. Alternately, an OAAM proxy can be set up so that end users communicate with that machine, which then communicates with the OAAM_Server application using HTTP(S). If the end user is authorized, he or she will be allowed to access the customer web application. The OAAM_ADMIN component is used for administration and configuration of the OAAM_SERVER application. The administrator responsible for administering and configuring the OAAM_Server application uses a web browser to access the OAAM_ADMIN application. An Oracle RAC database is used to hold policy and configuration information.

8.12.1.1 Oracle Adaptive Access Manager Component Characteristics

Oracle Adaptive Access Manager consists of the following two components:

OAAM_ADMIN: This component is used for administration and configuration of OAAM_SERVER application. This component is developed using the Oracle JAVA ADF Framework the Identity Management shell and deployed as Web applications in a J2EE container. It is packaged as an EAR file.
OAAM_SERVER: This component contains the OAAM Admin and OAAM Server sub-components within a single web application. The OAAM_SERVER component is packaged as an EAR file and is composed of Servlets and JSPs in addition to Java classes. The subcomponents of OAAM_SERVER are described below by layer:
- Presentation Layer: typically a Web application serving JSPs, servlets, and so on. The presentation layer provides the strong authenticator functionality; it uses the interfaces provided by the business layer (SOAP or Java native) to access its services.
- Business Logic Layer: this layer contains the core application logic that implements the risk analyzing engine. This layer provides Java and SOAP interfaces for the presentation layer. When the Java interface is used, the business logic layer and presentation layer can be part of a single web application. With the SOAP interface, these layers are deployed as different applications.
- Data Access Layer: contains data access components to connect to the supported relational databases. Oracle Adaptive Access Manager uses Oracle's TopLink, which provides a powerful and flexible framework for storing Java objects in a relational database.

The following components can also be used in an Oracle Adaptive Access Manager 11gR1 deployment:

Fusion Middleware Control / Enterprise Manager Grid Control: Oracle Adaptive Access Manager integrates with the Enterprise Manager Grid Control to display performance metrics and deployment topology. Oracle Adaptive Access Manager uses DMS and Discovery Mbeans to integrate with Enterprise Manager. Enterprise Manager is also used to enhance component tracing and configure auditing.

Enterprise Manager can also be used to view log files for each Managed Server in the domain and increase the tracing to Debug, Trace, and Info levels.
Data repositories: Oracle Adaptive Access Manager uses the RDBMS database as its data store. Oracle Adaptive Access Manager supports and works on the following database technologies:
- Oracle Real Application Clusters
- Oracle Data Guard
- Replication Streams
- Database Partitioning
Oracle Adaptive Access Manager uses RCU to creates its schema in the database.

8.12.1.1.1 Oracle Adaptive Access Manager State Information

The OAAM_Server component includes the OAAM Server subcomponent and the OAAM Admin subcomponent.

OAAM Server is a stateful application that stores the state in HTTP session.
OAAM Admin is a stateful application that stores its session information in the database.

The OAAM_Admin component is an ADF and Identity Management UI shell-based application. It is a stateless application, and its application state is maintained by the ADF framework.

8.12.1.1.2 Oracle Adaptive Access Manager Runtime Processes

You can perform the following runtime tasks using the Oracle Adaptive Access Manager Administration Console:

Customer Care application tasks
System configuration tasks involving policies, groups, and properties
Viewing session data information
Viewing the System Statistics dashboard

For example, you can perform the following administration flows:

Recent user query:
1. View recent logins and session details.
2. Perform a query.
3. Click Session Details.
4. Log out.
Manual CSR and Agent Case creation:
1. To reset customer care, log in.
2. Create a case.
3. Reset the customer.
4. Log out.

You can also perform runtime processing with the Oracle Adaptive Access Manager Server.

8.12.1.1.3 Oracle Adaptive Access Manager Process Lifecycle

The following runtime processing occurs with Oracle Adaptive Access Manager Server:

Oracle Adaptive Access Manager is deployed and integrated with the customer's application.
The user will access the customer's application and enter user credentials.
Based on the system and rules configured in OAAM, different login flows will be presented, for example:

User Registration: Registration Flows
1. Flow R1: Login (New User), enter password, personalize device, skip Questions Registration, log out.
2. Flow R2: Login, enter password, skip Registration, log out.
3. Flow R3: Login, enter password, personalize device, continue Questions Registration, log out.
4. Flow R4: Login, enter password, personalize device, continue Questions Registration, enter invalid answers, validation, log out
5. Flow R5: Login (New Device and New User), enter password, personalize device, continue Questions Registration, log out.
Login Flow:
1. Flow L1: Login, enter wrong password, Login screen.
2. Flow L2: Login, enter correct password, Challenge On may be presented, answer correctly, logged in.
3. Flow L3: Login, enter correct password, Challenge On presented, answer incorrectly, Challenge On presented again, answer correctly, logged in.
4. Flow L4: Login, enter correct password, Challenge On presented, answer incorrectly, Challenge On presented again, answer incorrectly, Challenge On presented again, answer correctly, logged in.
5. Flow L5: Login, enter correct password, Challenge On presented, answer incorrectly, Challenge On presented again, answer incorrectly, login blocked.
6. Flow L6: Login, enter correct password, login blocked (login screen).
7. Flow L7: Login, enter correct password, logged in.
8. Flow LNU1Login as a new user: Login, enter correct password, logged in.
9. Flow LND1: Existing user, login with a new device, enter correct password, logged in.
10. Flow LNUD1: New user, login with a new device, enter correct password, logged in.
In Session Transaction Flow: Login, enter password, create transaction, update transaction, log out.
OAAM tracks and registers the following data elements:
1. User login
2. User names
3. Devices (cookies, browser headers, and flash data supplied)
4. IP addresses
5. Transaction data
OAAM will trigger the appropriate policy based on login behavior.

As J2EE applications, the Oracle Adaptive Access Manager Server and Administration Console can be started using the user interface and command line tools provided by WebLogic Server.

The Oracle Adaptive Access Manager Server supports a health check request (a ping request over HTTP) that can be used by a load balancer for death detection.

Oracle Adaptive Access Manager is instrumented for server side metrics (using DMS) and this information is published to the Administration Console. When DMS metrics collection is enabled, monitoring the agent and server component metrics can serve as a proxy for component monitoring. In addition, Oracle Adaptive Access Manager supports fine-grained real time activity tracing, which can also serve as a proxy for component monitoring.

8.12.1.1.4 Oracle Adaptive Access Manager Configuration Artifacts

Oracle Adaptive Access Manager stores its configuration information in the database. These configuration properties can be changed using the Oracle Adaptive Access Manager Administration Console.

Oracle Adaptive Access Manager does not store any configuration information on the file system or in the exploded EAR file.

8.12.1.1.5 Oracle Adaptive Access Manager Deployment Artifacts

Oracle Adaptive Access Manager supports the nostage mode of deployment staging. That is, all deployment files are local.

8.12.1.1.6 Oracle Adaptive Access Manager External Dependencies

Oracle Adaptive Access Manager has an external dependency on the RDBMS database, where it stores its configuration information.

Oracle Adaptive Access Manager uses WebLogic Server multi data sources for Oracle RAC databases.

Oracle Adaptive Access Manager uses the standard Oracle TopLink object caching mechanism.

Oracle Adaptive Access Manager follows standard session object serialization to maintain the persistent state of an object.

Oracle Adaptive Access Manager is not dependent on any hostname, IP address, or port. It will work on a container-specific port or host name.

8.12.1.1.7 Oracle Adaptive Access Manager Log File Location

Oracle Adaptive Access Manager is a J2EE application deployed on WebLogic Server. All log messages are logged in the server log file of the WebLogic Server that the application is deployed on. The default location of the server log is:

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

8.12.2 Oracle Adaptive Access Manager High Availability Concepts

This section provides conceptual information about using Oracle Adaptive Access Manager in a high availability two-node cluster.

8.12.2.1 Oracle Adaptive Access Manager High Availability Architecture

Figure 8-17 shows the Oracle Adaptive Access Manager high availability architecture:

Figure 8-17 Oracle Adaptive Access Manager High Availability Architecture

Description of "Figure 8-17 Oracle Adaptive Access Manager High Availability Architecture"

In Figure 8-17, incoming requests are received by the hardware load balancer, which routes them to WEBHOST1 or WEBHOST2 in the web tier. These hosts have Oracle HTTP Server installed. The Oracle HTTP Server then forwards requests on to the WebLogic managed servers on OAAMHOST1 and OAAMHOST2 using the WebLogic plugin mod_wl_ohs.

OAAMHOST1 and OAAMHOST2 contain managed servers which host the Oracle Adaptive Access Manager Server application and the Oracle Adaptive Access Manager Admin application. These managed servers are configured in a cluster which allows the Access Servers to work in an active-active manner.

The WebLogic Administration Server runs on OAAMHOST1 and contains the WebLogic Administration Console and the Oracle Enterprise Manager Fusion Middleware Control. The Administration Server can be configured to run in active-passive mode on OAAMHOST2, which means that if OAAMHOST1 becomes unavailable, then Administration Server can be manually started on OAAMHOST2.

An Oracle RAC database provides high availability in the data tier.

Figure 8-17 shows the OAAM high availability configuration architecture. In the figure, a load balancer routes requests through two Oracle HTTP Server instances on WEBHOST1 and WEBHOST2 to OAAMHOST1 and OAAMHOST2. An OAAM Administration Server instance and an OAAM Managed Server instance is installed on OAAMHOST1 and on OAAMHOST2, and these installations are configured as an OAAM Server cluster (OAAM_Cluster) and an OAAM Admin Cluster (OAAM_Admin_Cluster). The OAAM Server cluster uses the OAAM Server data source and the OAAM Admin cluster uses the OAAM Admin data source to communicate with the Oracle RAC database.

As shown in Figure 8-17, only one Oracle Adaptive Access Manager Server cluster and one Oracle Adaptive Access Manager Administration cluster is supported per WebLogic Server domain. In addition, Oracle Adaptive Access Manager-related clusters cannot span WebLogic Server domains.

A single instance Oracle Adaptive Access Manager deployment satisfies the following high availability requirements:

Load handling
External connection management and monitoring
Recovery
Fault containment
Fault diagnostics
Oracle Adaptive Access Manager Admin / Server offline

A multiple instance Oracle Adaptive Access Manager deployment satisfies the following additional high availability requirements:

Redundancy
Client connection failover / continuity
Client load balancing
State management

Use of external load balancing routers is recommended for inbound HTTP connections.

Web sessions open persistent TCP connections to the Oracle Adaptive Access Manager Administration Console and servers. This requires that load balancing router and firewall connection timeouts are sufficiently large to avoid premature termination of TCP connections.

8.12.2.1.1 Starting and Stopping the Cluster

Each Oracle Adaptive Access Manager Administration Console and Server instance is a peer of other instances. Because all initialization happens before the Server is ready to receive requests and because of built in throttling capabilities, surge conditions are dealt with gracefully without any significant impact of the performance characteristics of the Oracle Adaptive Access Manager 11gR1 Access Server.

When the cluster is stopped, new requests will be denied and existing requests will be allowed to complete before the Oracle Adaptive Access Manager Administration Console and Server application shuts down. In the event of a forced shutdown, Oracle Adaptive Access Manager 11gR1 can recover any corrupted or invalid data caused by the forced shutdown.

Oracle Adaptive Access Manager components are pure J2EE applications, and they do not have any start or stop functionality of their own. Instead, they rely on container-specific startup and shutdown functionality.

Oracle Adaptive Access Manager components are deployed to WebLogic Server Managed Server nodes. The components can be restarted using Node Manager.

8.12.2.1.2 Cluster-Wide Configuration Changes

Since Oracle Adaptive Access Manager stores the entire configuration in database, the propagation of configuration changes to all the cluster members transparent. All Oracle Adaptive Access Manager components are notified of change events from the internal layer, which are then taken up by the components. To ensure atomicity of the change, Oracle Adaptive Access Manager components reload their entire configuration every time a change happens.

Oracle Adaptive Access Manager configuration applies to every instance in a cluster.

Adding and removing Oracle Adaptive Access Manager Administration Console and Server instances is transparent to other Oracle Adaptive Access Manager instances in the cluster.

An Oracle Adaptive Access Manager cluster can have any number of instances. There is no restriction on the number of instances per cluster.

Online application redeployment does not cause any problems.

8.12.2.2 Protection from Failures and Expected Behaviors

The following features protect an Oracle Adaptive Access Manager high availability configuration from failure:

Session state for the cluster is maintained in memory, which provides replication and failover for all session state information.
Oracle Adaptive Access Manager Servers support a heart beat check - a ping request over HTTP. In addition, the WebLogic Node Manager on the Managed Server can monitor the application and restart it if it is not running. Restarting an Oracle Adaptive Access Manager Server has no impact on any other running components or cluster members.
When a WebLogic Server node fails, external connection failover is based on the configuration and is based on the retry timeout as well as the number of retries.
When the load balancing router or proxy server detects a WebLogic Server node failure, subsequent client connections are routed to the active instance, which picks up the session state for further processing.
An Oracle Adaptive Access Manager session does not have a direct impact on an Oracle RAC database node failure, because WebLogic Server maintains the state of its database connections.

8.12.3 Oracle Adaptive Access Manager High Availability Configuration Steps

This section provides high-level instructions for setting up a maximum high availability deployment for Oracle Adaptive Access Manager. This deployment includes two Oracle HTTP Servers, which distribute requests to two OAAM servers. These OAAM servers interact with an Oracle Real Application Clusters (Oracle RAC) database. If any single component fails, then the remaining components will continue to function.

This section includes the following topics:

Section 8.12.3.1, "Prerequisites for Oracle Adaptive Access Manager Configuration"
Section 8.12.3.2, "Run the Repository Creation Utility to Create the OAAM Schemas in a Database"
Section 8.12.3.3, "Installing Oracle WebLogic Server"
Section 8.12.3.4, "Install and Configure the Oracle Adaptive Access Manager Application Tier"
Section 8.12.3.5, "Creating boot.properties for the Administration Server on OAAMHOST1"
Section 8.12.3.6, "Create the Oracle Adaptive Access Manager Administration User"
Section 8.12.3.7, "Start OAAMHOST1"
Section 8.12.3.8, "Validating OAAMHOST1"
Section 8.12.3.9, "Configure Oracle Adaptive Access Manager on OAAMHOST2"
Section 8.12.3.10, "Start OAAMHOST2"
Section 8.12.3.11, "Validating OAAMHOST2"
Section 8.12.3.12, "Configure Oracle Adaptive Access Manager to Work with Oracle HTTP Server"
Section 8.12.3.13, "Validating the Oracle Adaptive Access Manager Configuration"
Section 8.12.3.14, "Scaling Up and Scaling Out the Oracle Adaptive Access Manager Topology"

8.12.3.1 Prerequisites for Oracle Adaptive Access Manager Configuration

Before you configuring Oracle Adaptive Access Manager for high availability, you must:

Run the Repository Creation Utility to create the OAAM schemas in a database.

See Section 8.12.3.2, "Run the Repository Creation Utility to Create the OAAM Schemas in a Database" for instructions on running the Repository Creation Utility to create the OAAM schemas.
Install Oracle WebLogic Server on OAAMHOST1 and OAAMHOST2.

Follow the steps in Section 8.12.3.3, "Installing Oracle WebLogic Server" to install Oracle WebLogic Server on OAMHOST1 and OAMHOST2.
Install and configure the Oracle Identity Management executables on OAAMHOST1 and OAAMHOST2.

Follow the steps in Section 8.12.3.4, "Install and Configure the Oracle Adaptive Access Manager Application Tier" to install the Oracle Identity Management executables on OAAMHOST1 and OAAMHOST2.

8.12.3.2 Run the Repository Creation Utility to Create the OAAM Schemas in a Database

See Section 8.2.4.1, "Executing the Repository Creation Utility" for instructions on running the Repository Creation Utility to create the OAAM schemas in your database repository.

8.12.3.3 Installing Oracle WebLogic Server

Start the installer, then proceed as follows:

On the Welcome screen, click Next.
On the Choose Middleware Home Directory screen, select Create a New Middleware Home.

For Middleware Home Directory, enter:

ORACLE_BASE/product/fmw

Note:
ORACLE_BASE is the base directory under which Oracle products are installed. The recommended value is /u01/app/oracle.

Click Next.
On the Register for Security Updates screen, enter your contact information so that you can be notified of security updates.

Click Next.
On the Choose Install Type screen, select Custom.

Click Next.
On the Choose Products and Components screen, select only Oracle JRockit SDK, and click Next.
On the Choose Product Installation Directories screen, accept the directory ORACLE_BASE/product/fmw/wlserver_10.3.

Click Next.
On the Installation Summary screen, click Next.
On the Installation Complete screen, deselect Run Quickstart.

Click Done.

8.12.3.4 Install and Configure the Oracle Adaptive Access Manager Application Tier

Perform these steps to install Oracle Fusion Middleware Components on OAAMHOST1 and OAAMHOST2.

Start the installer for Oracle Fusion Middleware as follows:

OAAMHOST1> runInstaller

Then proceed as follows:

On the Welcome screen, click Next.
On the Prerequisite Checks screen, verify that the checks complete successfully, then click Next.
On the Specify Installation Location screen, enter the following values:
- Oracle Middleware Home: Select the previously installed Middleware home from the list for MW_HOME, for example:
```
/u01/app/oracle/product/fmw
```
- Oracle Home Directory:
  - Enter idm as the Oracle Home directory name when installing the Oracle Identity Management Suite in the IDM_ORACLE_HOME.
  - Enter iam as the Oracle Home directory name when installing the Oracle Identity and Access Management Suite in the IAM_ORACLE_HOME.Enter soa as the Oracle Home directory name when installing the Oracle SOA Suite in the SOA_ORACLE_HOME.
Click Next.
On the Installation Summary screen, click Install and Configure.
In the Welcome screen, select Create a New WebLogic Domain, and then click Next.
In the Select Domain Source Screen:

Select Generate a domain configured automatically to support the following products:

And select the following products:
- Oracle Enterprise Manager
- Oracle JRF (selected by default)
- Oracle Adaptive Access Manager - Server
- Oracle Adaptive Access Manager Admin Server
Click Next.
In the Specify Domain and Location screen enter:
- Domain name: IDM_Domain
- Domain Directory: Accept the default.
- Application Directory: Accept the default.
Click Next.
In the Configure Administrator Username and Password screen, enter the username and password to be used for the domain's administrator, and click Next.
In the Configure Server Start Mode and JDK screen, make the following selections:
- WebLogic Domain Startup Mode: Select Production Mode.
- JDK Selection: Select JROCKIT SDK1.6.0_17 SDK.
In the Configure JDBC Component Schema screen, select all of the data sources, then select Configure selected data sources as RAC multi data sources.

Click Next.
In the Configure RAC Multi Data Source Component Schema screen, select the first data source, OAAM Admin Server, and enter the following:
- Data source: OAAM Admin Server
- Service Name: oaam.mycompany.com
- User Name: OAAM_OAAM (assuming OAAM was used as the RCU prefix)
- Password: The password for above account
In the top right box, click Add to add an Oracle RAC host. Enter the following information:
- Host Name: OAAMDBHOST1
- Instance Name: oaamdb1
- Port: 1521
Click Add again to add the second database host and enter the following information:
- Host Name: OAAMDBHOST2
- Instance Name: oaamdb2
- Port: 1521
Deselect this data source. Select the next data source, OAAM Admin MDS Schema, and enter the following information:
- Data Source: OAAM Admin MDS Schema
- Service Name: oaam.mycompany.com
- User Name: OAAM_MDS (assuming OAAM was used as the RCU prefix)
- Password: Password for the OAAM_MDS account.
In the top right box, click Add to add an Oracle RAC host. Enter the following information:
- Host Name: OAAMDBHOST1
- Instance Name: oaamdb1
- Port: 1521
Click Add again to add the second database host and enter the following information:
- Host Name: OAAMDBHOST2
- Instance Name: oaamdb2
- Port: 1521
Deselect this data source. Select the next data source, OAAM Server, and enter the following information:
- Data Source: OAAM Server
- Service Name: oaam.mycompany.com
- User Name: OAAM_OAAM (assuming OAAM was used as the RCU prefix)
- Password: Password for the OAAM_OAAM account.
In the top right box, click Add to add an Oracle RAC host. Enter the following information:
- Host Name: OAAMDBHOST1
- Instance Name: oaamdb1
- Port: 1521
Click Add again to add the second database host and enter the following information:
- Host Name: OAAMDBHOST2
- Instance Name: oaamdb2
- Port: 1521
Deselect this data source. Select the next data source, OWSM MDS Schema, and enter the following information:
- Data Source: OWSM MDS Schema
- Service Name: oaam.mycompany.com
- User Name: OAAM_MDS (assuming OAAM was used as the RCU prefix)
- Password: Password for the OAAM_MDS account.
In the top right box, click Add to add an Oracle RAC host. Enter the following information:
- Host Name: INFRADBHOST1
- Instance Name: oaamdb1
- Port: 1521
Click Add again to add the second database host and enter the following information:
- Host Name: INFRADBHOST2
- Instance Name: oaamdb2
- Port: 1521
Deselect this data source.

Click Next.
In the Test Component Schema screen, the configuration wizard attempts to validate the data source.

If the data source validation succeeds, click Next.

If it fails, click Previous, correct the issue, and try again.
In the Select Optional Configuration screen, select:
- Administration Server
- Managed Server Clusters and Machines
Click Next.
In the Customize Server and Cluster Configuration screen, select Yes, and click Next.
In the Configure the Administration Server screen, enter the following values:
- Name: AdminServer
- Listen Address: Enter the virtual host name of the Administration Server, for example: OAAMHOST1.mycompany.com
- Listen Port: 7001
- SSL listen port: Not applicable
- SSL enabled: leave unchecked
Click Next.
On the Configure Managed Servers screen, create two entries for each OAAMHOST in the topology, that is, one for the OAAM Server and one for the OAAM Admin Server.

Select the OAAM_SERVER entry and change the entry to the following values:
- Name: WLS_OAAM1
- Listen Address: OAAMHOST1.mycompany.com
- Listen Port: 14300
- SSL Listen Port: 14301
- SSL Enabled: Selected
For the second OAAM_SERVER, click Add and supply the following information:
- Name: WLS_OAAM2
- Listen Address: OAAMHOST2.mycompany.com
- Listen Port: 14300
- SSL Listen Port: 14301
- SSL Enabled: Selected
Select the OAAM_ADMIN_SERVER entry and change the entry to the following values:
- Name: WLS_OAAM_ADMIN1
- Listen Address: OAAMHOST1.mycompany.com
- Listen Port: 14200
- SSL Listen Port: 14201
- SSL Enabled: Selected
For the second OAAM_ADMIN_SERVER, click Add and supply the following information:
- Name: WLS_OAAM_ADMIN2
- Listen Address: OAAMHOST2.mycompany.com
- Listen Port: 14200
- SSL Listen Port: 14201
- SSL Enabled: Selected
Leave all other fields at the default settings.

Click Next.
In the Configure Clusters screen, create a cluster by clicking Add.

Enter name: OAAM_Cluster

Create a second cluster by clicking Add.

Enter name: OAAM_Admin_Cluster

Leave all other fields at the default settings.

Click Next.
On the Assign Servers to Clusters screen, associate the managed servers with the cluster, as follows:
- Click the cluster name OAAM_Cluster in the right window.
- Click the managed server WLS_OAAM1, then click the arrow to assign it to the cluster.
- Repeat for managed server WLS_OAAM2.
Then:
- Click the cluster name OAAM_Admin_Cluster in the right window.
- Click the managed server WLS_OAAM_ADMIN1, then click the arrow to assign it to the cluster.
- Repeat for managed server WLS_OAAM_ADMIN2.
Click Next.
On the Configure Machines screen, create a machine for each host in the topology. Click the UNIX tab if your hosts use a UNIX-based operating system. Otherwise, click the Machines tab. Supply the following information:
- Name: Name of the host. The best practice is to use the DNS name (OAAMHOST1)
- Node Manager Listen Address: The DNS name of the machine (OAAMHOST1.mycompany.com)
- Node Manager Port: A port for Node Manager to use.
Click Next.
In the Assign Servers to Machines screen, indicate which managed servers will run on the machines just created.

For OAAMHOST1:
- Click the machine OAAMHOST1 in the right window.
- Click the managed server WLS_OAAM1 in the left window.
- Click the arrow to assign the managed server to the host OAAMHOST1.
- Click the managed server WLS_OAAM_ADMIN1 in the left window.
- Click the arrow to assign the managed server to the host OAAMHOST1.
For OAAMHOST2:
- Click the machine OAAMHOST2 in the right window.
- Click the managed server WLS_OAAM2 in the left window.
- Click the arrow to assign the managed server to the host OAAMHOST2.
- Click the managed server WLS_OAAM_ADMIN2 in the left window.
- Click the arrow to assign the managed server to the host OAAMHOST2.
Click Next.
On the Configuration Summary screen, click Create to begin the creation process.

When prompted, on Linux and UNIX installations, execute the script oracleRoot.sh as the root user.

8.12.3.5 Creating boot.properties for the Administration Server on OAAMHOST1

This section describes how to create a boot.properties file for the Administration Server on OAAMHOST1. 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 OAAMHOST1, 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 OAAMHOST1 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://oaamhost1.mycompany.com:7001/console
```
- Oracle Enterprise Manager Fusion Middleware Control at:
```
http://oaamhost1.mycompany.com:7001/em
```
Log into these consoles using the weblogic user credentials.

8.12.3.6 Create the Oracle Adaptive Access Manager Administration User

Create an Administrative user, which will be used to access the OAAM console. To do this, perform these steps:

Log into the WebLogic Administration Console using this URL:
```
http://oaamhost1.mycompany.com:7001/console
```
From the Domain Structure menu, click Security Realms and then myrealm.
Click the Users and Groups tab.
Click the Users sub tab.
Click New.
Enter these values:
- Name: Name for the user, for example: oaam_admin
- Provider: Default Authenticator
- Password/Confirmation: Password for user
Click OK.
Once the user has been created, click the user name.
Click on the Groups sub tab.
Assign the user to the following groups:
- OAAMCSRGroup
- OAAMCSRManagerGroup
- OAAMInvestigatorGroup
- OAAMInvestigationManagerGroup
- OAAMRuleAdministratorGroup
- OAAMEnvAdminGroup
- OAAMSOAPServicesGroup
Click Save.

8.12.3.7 Start OAAMHOST1

Now you will start OAAMHOST1.

This section describes the steps for starting OAAMHOST1.

8.12.3.7.1 Create the Node Manager Properties File on OAAMHOST1

OAAMHOST1> $MW_HOME/oracle_common/common/bin/setNMProps.sh

8.12.3.7.2 Start Node Manager

Start Node Manager by issuing the following command:

OAAMHOST1> $MW_HOME/wlserver_10.3/server/bin/startNodeManager.sh

8.12.3.7.3 Start Oracle Adaptive Access Manager on OAAMHOST1

To start Oracle Adaptive Access Manager on OAAMHOST1, follow these steps:

Log into the WebLogic Administration Console using this URL:
```
http://oaamhost1.mycompany.com:7001/console
```
Supply the WebLogic administrator username and password.
Select Environment - Servers from the Domain Structure menu.
Click the Control tab.
Click the servers WLS_OAAM1 and WLS_OAAM_ADMIN1.
Click Start.
Click OK to confirm that you want to start the servers.

8.12.3.8 Validating OAAMHOST1

Validate the implementation by connecting to the OAAM Administration Server at the following URL:

http://OAAMHOST1.mycompany.com:14200/oaam_admin

The implementation is valid if the OAAM Admin console login page is displayed and you can login using the oaamadmin account you created in Section 8.12.3.6, "Create the Oracle Adaptive Access Manager Administration User."

Validate the implementation by connecting to the OAAM Server at:

http://OAAMHOST1.mycompany.com:14300/oaam_server

The implementation is valid if the OAAM Server login page is displayed.

8.12.3.9 Configure Oracle Adaptive Access Manager on OAAMHOST2

Once the configuration has succeeded on OAAMHOST1, you can propagate it to OAAMHOST2. You do this by packing the domain using the pack script on OAAMHOST1, and unpacking the domain using the unpack script on OAAMHOST2.

Both scripts reside in the MW_HOME/oracle_common/common/bin directory.

On OAAMHOST1, enter:

pack.sh -domain=$MW_HOME/user_projects/domains/IDM_Domain \
    -template=/tmp/idm_domain.jar -template_name="OAAM Domain" -managed=true

This creates a file called idm_domain.jar in the /tmp directory. Copy this file to OAAMHOST2.

On OAAMHOST2, enter:

unpack.sh -domain=$MW_HOME/user_projects/domains/IDM_Domain \
    -template=/tmp/idm_domain.jar

8.12.3.10 Start OAAMHOST2

Now you will start OAAMHOST2.

This section describes the steps for starting OAAMHOST2.

8.12.3.10.1 Create the Node Manager Properties File on OAAMHOST2

OAAMHOST1> $MW_HOME/oracle_common/common/bin/setNMProps.sh

8.12.3.10.2 Start Node Manager

Start Node Manager by issuing the following command:

OAAMHOST2> $MW_HOME/wlserver_10.3/server/bin/startNodeManager.sh

8.12.3.10.3 Start Oracle Adaptive Access Manager on OAAMHOST2

To start Oracle Adaptive Access Manager on OAAMHOST2, follow these steps:

Log into the WebLogic Administration Console using this URL:
```
http://oaamhost2.mycompany.com:7001/console
```
Supply the WebLogic administrator username and password.
Select Environment - Servers from the Domain Structure menu.
Click the Control tab.
Click the servers WLS_OAAM2 and WLS_OAAM_ADMIN2.
Click Start.
Click OK to confirm that you want to start the servers.

8.12.3.11 Validating OAAMHOST2

Validate the implementation by connecting to the OAAM Administration Server at the following URL:

http://OAAMHOST2.mycompany.com:14200/oaam_admin

The implementation is valid if OAAM Admin console login page is displayed and you can login using the oaamadmin account you created in Section 8.12.3.6, "Create the Oracle Adaptive Access Manager Administration User."

Validate the implementation by connecting to the OAAM Server at:

http://OAAMHOST2.mycompany.com:14300/oaam_server

The implementation is valid if the OAAM Server login page is displayed.

8.12.3.12 Configure Oracle Adaptive Access Manager to Work with Oracle HTTP Server

This section provides steps for configuring Oracle Adaptive Access Manager to work with the Oracle HTTP Server.

8.12.3.12.1 Update Oracle HTTP Server Configuration

On WEBHOST1 and WEBHOST2, create a file named oaam.conf in the following directory:

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

Create the file with the following lines:

NameVirtualHost *:7777
<VirtualHost *:7777>
 
    ServerName oaam.mycompany.com:7777
    ServerAdmin you@your.address
    RewriteEngine On
    RewriteOptions inherit
 
    <Location /oaam_server>
       SetHandler weblogic-handler
       WebLogicCluster oaamhost1.mycompany.com:14300,oaamhost2.mycompany.com:14300
    </Location>
 
    <Location /oaam_admin>
       SetHandler weblogic-handler
       WebLogicCluster oaamhost1.mycompany.com:14200,oaamhost2.mycompany.com:14200
       WebLogicPort 7001
    </Location>
 
</VirtualHost>

8.12.3.12.2 Restart Oracle HTTP Server

Restart the Oracle HTTP Server on WEBHOST1 and WEBHOST2:

WEBHOST1>opmnctl stopall
WEBHOST1>opmnctl startall

WEBHOST2>opmnctl stopall
WEBHOST2>opmnctl startall

8.12.3.12.3 Change Host Assertion in WebLogic

Because the Oracle HTTP Server acts as a proxy for WebLogic, by default certain CGI environment variables are not passed through to WebLogic. These include the host and port. You must tell WebLogic that it is using a virtual site name and port so that it can generate internal URLs appropriately.

To do this, log into the WebLogic Administration Console at:

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

Then perform these steps:

Select Clusters from the home page, or select Environment > Clusters from the Domain Structure menu.
Click Lock and Edit in the Change Center window to enable editing.
Click the Cluster Name (oaam_cluster).
In the General tab, set WebLogic Plug in to Enabled by checking the box in the Advanced Properties section.
Click Save.
Select HTTP and enter the following values:
- Frontend Host: oaam.mycompany.com
- Frontend HTTP Port: 7777
- Frontend HTTPS Port: Set to SSL port on the load balancer or the Oracle HTTP Server SSL port if using SSL communication.
This ensures that any HTTPS URLs created from within WebLogic are directed to port 443 or 80 on the load balancer.
Click Save.
Select Clusters from the home page, or select Environment > Clusters from the Domain Structure menu.
Click the Cluster Name (oaam_admin_cluster).
In the General tab, set WebLogic Plug in to Enabled by checking the box in the Advanced Properties section.
Click Save.
Select HTTP and enter the following values:
- Frontend Host: oaam.mycompany.com
- Frontend HTTP Port: 7777
- Frontend HTTPS Port: Set to SSL port on the load balancer or the Oracle HTTP Server SSL port if using SSL communication.
Click Save.
Click Activate Changes in the Change Center window to save the changes.
Restart managed servers WLS_OAAM1, WLS_OAAM2, WLS_OAAM_ADMIN1 and WLS_OAAM_ADMIN2 as follows:
1. Log into the WebLogic Administration Console using this URL:
```
http://oaamhost1.mycompany.com:7001/console
```
2. Supply the WebLogic administrator username and password.
3. Select Environment - Servers from the Domain Structure menu.
4. Click the Control tab.
5. Click the servers WLS_OAAM1, WLS_OAAM2, WLS_OAAM_ADMIN1, and WLS_OAAM_ADMIN2.
6. Click Shutdown - Force shutdown now.
7. Click Yes to confirm that you want to stop the servers.
8. Select Environment - Servers from the Domain Structure menu.
9. Click the Control tab.
10. Click the servers WLS_OAAM1, WLS_OAAM2, WLS_OAAM_ADMIN1, and WLS_OAAM_ADMIN2.
11. Click Start.
12. Click Yes to confirm that you want to start the servers.
Restart the Administration Server.

8.12.3.13 Validating the Oracle Adaptive Access Manager Configuration

Log into the Oracle Adaptive Access Manager Administration Console at http://oaam.mycompany.com:7777/oaam_admin using the oaamadmin account you created.

Also, log into the Oracle Adaptive Access Manager server at http://oaam.mycompany.com:7777/oaam_server using the oaamadmin account and the password test.

8.12.3.14 Scaling Up and Scaling Out the Oracle Adaptive Access Manager Topology

This section describes how to scale up and scale out an Oracle Adaptive Access Manager high availability topology. Perform a scale up operation to add a new Oracle Adaptive Access Manager managed server instance is added to a node already running one or more server instances. Perform a scale out operation to add a new Oracle Adaptive Access Manager managed server instance to a new node.

8.12.3.14.1 Scaling Up Oracle Adaptive Access Manager

To scale up OAAM, use the same procedure for both the OAAM server and the OAAM Administration Server.

From the Domain Structure window of the Oracle WebLogic Server Administration Console, expand the Environment node and then Servers. The Summary of Servers page appears.
Click Lock & Edit from the Change Center menu.
Select an existing server on the host that you want to extend, for example: WLS_OAAM1 or WLS_OAAM_ADMIN1.
Click Clone.
Enter the following information:
- Server Name: A new name for the server, for example: WLS_OAAM3.
- Server Listen Address: The name of the host on which the managed server will run.
- Server Listen Port: The port the new managed server will use. This port must be unique within the host.
Click OK.
Click the newly-created server WLS_OAAM3.
Set the SSL listen port. This should be unique on the host that the managed server will be running on.
Click Save.
Disable host name verification for the new managed server. Before starting and verifying the WLS_OAAM3 managed server, you must disable host name verification. You can re-enable it after you have configured server certificates for the communication between the Oracle WebLogic Administration Server and the Node Manager in OAAMHOSTn.

If the source server from which the new one was cloned had already disabled hostname verification, these steps are not required, as the hostname verification settings were propagated to the cloned server. To disable host name verification:
1. In the Oracle Fusion Middleware Enterprise Manager Console, select Oracle WebLogic Server Administration Console.
2. Expand the Environment node in the Domain Structure pane.
3. Click Servers. The Summary of Servers page appears.
4. Select WLS_OAAM3 in the Names column of the table. The Settings page for server appears.
5. Click the SSL tab.
6. Click Advanced.
7. Set Hostname Verification to None.
8. Click Save.
Click Activate configuration from the Change Center menu.

8.12.3.14.2 Scaling Out Oracle Adaptive Access Manager

Scale out is very similar to scale up, but first requires the software to be installed on the new node. Proceed as follows:

Install Oracle WebLogic Server on the new host as described in Section 8.12.3.3, "Installing Oracle WebLogic Server."
Install Oracle Fusion Middleware Identity Management components on the new host as described in Section 8.12.3.4, "Install and Configure the Oracle Adaptive Access Manager Application Tier."
Log in to the WebLogic console at http://oaamhost1.mycompany.com:7001/console.
From the Domain Structure pane of the Oracle WebLogic Server Administration Console, expand the Environment node and then Servers. The Summary of Servers page appears.
Click Lock & Edit from the Change Center menu.
Select an existing server on the host you want to extend, for example: WLS_OAAM1 or WLS_OAAM_ADMIN1.
Click Clone.
Enter the following information:
- Server Name: A new name for the server, for example: WLS_OAAM3
- Server Listen Address: The name of the host on which the managed server will run.
- Server Listen Port: The port the new managed server will use. This port must be unique within the host.
Click OK.
Click the newly-created server WLS_OAAM3.
Set the SSL listen port. This should be unique on the host that the managed server will be running on.
Click Save.
Disable host name verification for the new managed server. Before starting and verifying the WLS_OAAM3 managed server, you must disable host name verification. You can re-enable it after you have configured server certificates for the communication between the Oracle WebLogic Administration Server and the Node Manager in OAAMHOSTn.

If the source server from which the new one was cloned had already disabled hostname verification, these steps are not required, as the hostname verification settings were propagated to the cloned server. To disable host name verification:
1. In the Oracle Fusion Middleware Enterprise Manager Console, select Oracle WebLogic Server Administration Console.
2. Expand the Environment node in the Domain Structure pane.
3. Click Servers. The Summary of Servers page appears.
4. Select WLS_OAAM3 in the Names column of the table. The Settings page for server appears.
5. Click the SSL tab.
6. Click Advanced.
7. Set Hostname Verification to None.
8. Click Save.
Click Activate configuration from the Change Center menu.

Pack the domain on OAAMHOST1 using the command:

pack.sh -domain=ORACLE_BASE/admin/IDM_Domain/aserver/IDM_Domain -template =/tmp/idm_domain.jar -template_name="OAAM Domain" -managed=true

The pack.sh script is located in MW_HOME/oracle_common/common/bin.

Unpack the domain on the new host using the command:

unpack.sh -domain=ORACLE_BASE/admin/IDM_Domain/mserver/IDM_Domain -template=/tmp/idm_domain.jar -template_name="OAAM Domain" -app_dir=ORACLE_BASE/admin/IDM_Domain/mserver/applications

The unpack.sh script is located in MW_HOME/oracle_common/common/bin.

Before you can start managed servers from the console, you must create a node manager properties file on OAAMHOST2 by running the script setNMProps.sh. The setNMProps.sh script is located in MW_HOME/oracle_common/common/bin. Type:
```
OAAMHOST2> $MW_HOME/oracle_common/common/bin/setNMProps.sh
```
Start Node Manager and the new managed server on the new host
Now that the new managed server has been created and started, the web tier will start to direct requests to it. Best practice, however, is to inform the web server that the new managed server has been created.

You do this by updating the file oaam.conf on each of the web tiers. This file resides in the directory: ORACLE_INSTANCE/config/OHS/component_name/moduleconf.

Add the new server to the WebLogicCluster directive in the file. For example, change:
```
<Location /oaam_admin>
    SetHandler weblogic-handler
    WebLogicCluster oaamhost1.mycompany.com:14200,oaamhost2.mycompany.com:14200
</Location>
```
to:
```
<Location /oaam_admin>
    SetHandler weblogic-handler
    WebLogicCluster
oaamhost1.mycompany.com:14200,oaamhost2.mycompany.com:14200,oaamhost3.mycompany.com:14300
</Location>
```

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

8.13.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 8-18 Oracle Identity Federation Non-High Availability Architecture

Description of "Figure 8-18 Oracle Identity Federation Non-High Availability Architecture"

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

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

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

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

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

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

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

8.13.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 8-11 shows the relationship between the deployment option and the required transient data store type:

Table 8-11 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 8-12 shows the relationship between the deployment option and the required configuration data store type:

Table 8-12 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 8-13 shows the relationship between the deployment option and the required federation data store type:

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

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

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

8.13.2.1 Oracle Identity Federation High Availability Architecture

Figure 8-19 shows the Oracle Identity Federation high availability architecture in an active-active configuration.

Figure 8-19 Oracle Identity Federation in a High Availability Architecture

Description of "Figure 8-19 Oracle Identity Federation in a High Availability Architecture"

In Figure 8-19, 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 Oracle RAC database has been configured in a JDBC multi data source to protect the instance from Oracle 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 Oracle RAC database has been configured in a JDBC multi data source to protect the instance from Oracle 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.

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

8.13.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 patch set, otherwise the session replication changes are lost.

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

8.13.2.3 Oracle Identity Federation Prerequisites

Oracle Identity Federation requires the following components:

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

8.13.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 latest version of the Repository Creation Utility (RCU) to create the collection of schemas used by Oracle Identity Federation.

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

Follow these steps to run RCU and create the Oracle Identity Federation schemas in an Oracle 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 an Oracle RAC database, specify the VIP name or one node name. Example: INFRADBHOST1-VIP or INFRADBHOST2-VIP

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

Service Name: The service name of the database. Example: oif.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.

8.13.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 8.13.3.1, "Configuring Oracle Identity Federation on OIFHOST1"
Section 8.13.3.2, "Creating boot.properties for the Administration Server on OIFHOST1"
Section 8.13.3.3, "Configuring Oracle Identity Federation on OIFHOST2"
Section 8.13.3.4, "Post-Installation Steps for Oracle Identity Federation"
Section 8.13.3.5, "Configuring the Load Balancer"
Section 8.13.3.6, "Validating Oracle Identity Federation High Availability"
Section 8.13.3.7, "Enabling Oracle Identity Federation Integration with Highly Available LDAP Servers"

8.13.3.1 Configuring Oracle Identity Federation on OIFHOST1

Follow these steps to 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 Oracle Identity Management software has been installed and upgraded on OIFHOST1 as described in Section 8.3.3.1, "Installing Oracle Fusion Middleware Components."
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 port for OIF Server port
OIF Server Port No = 7499
```
Start the Oracle Identity Management 11g Configuration Assistant located under the ORACLE_HOME/bin directory as follows:

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

On Windows, double-click config.exe
On the Welcome screen, 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: This value is prefilled and cannot be updated.
```
/u01/app/oracle/product/fmw
```
- Oracle Home Directory: This value is prefilled and cannot be updated.
```
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:oifdb1^infradbhost2-vip.mycompany.com:
1521:oifdb2@oif.mycompany.com
```
  Note:
  The Oracle RAC database connect string information needs to be provided in the format host1:port1:instance1^host2:port2:instance2@servicename.
  During this installation, it is not required for all the Oracle RAC instances to be up. If one Oracle RAC instance is up, the installation can proceed.
  
  It is required that the information provided above is complete and accurate. Specifically, the correct host, port, and instance name must be provided for each Oracle RAC instance, and the service name provided must be configured for all the specified Oracle RAC instances.
  
  Any incorrect information entered in the Oracle RAC database connect string has to be corrected manually after the installation.
- 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.

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

8.13.3.3 Configuring Oracle Identity Federation on OIFHOST2

Follow these steps to 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.
Ensure that Oracle Identity Management software has been installed and upgraded on OIFHOST2 as described in Section 8.3.3.1, "Installing Oracle Fusion Middleware Components."
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 port for OIF Server port
OIF Server Port No = 7499
```
Start the Oracle Identity Management 11g Configuration Assistant located under the ORACLE_HOME/bin directory as follows:

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

On Windows, double-click config.exe
On the Welcome screen, 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: This value is prefilled and cannot be updated.
```
/u01/app/oracle/product/fmw
```
- Oracle Home Directory: This value is prefilled and cannot be updated.
```
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.

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

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

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

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

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

8.13.3.5.1 Load Balancer Virtual Server Name Setup

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

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

8.13.3.6 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
```

8.13.3.7 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. Use the WLST script located under the $ORACLE_HOME/common/bin directory.

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')
```

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

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

8.13.4.2 Performing an Oracle RAC Failover

Follow these steps to perform an Oracle 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

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

8.14 Starting and Stopping Oracle Identity Management Components

This section describes how to start, stop and restart various components described in this chapter.

This section contains the following topics:

Section 8.14.1, "Oracle Internet Directory"
Section 8.14.2, "Oracle Virtual Directory"
Section 8.14.3, "Oracle HTTP Server"
Section 8.14.4, "Node Manager"
Section 8.14.5, "WebLogic Administration Server"
Section 8.14.6, "Oracle Identity Manager"
Section 8.14.7, "Oracle Access Manager Managed Servers"
Section 8.14.8, "Oracle Adaptive Access Manager Managed Servers"
Section 8.14.9, "Oracle Identity Federation"

8.14.1 Oracle Internet Directory

Starting

Start system components such as Oracle Internet Directory by typing

ORACLE_INSTANCE/bin/opmnctl startall

You can verify that the system components have started by executing:

ORACLE_INSTANCE/bin/opmnctl status -l

Stopping

Stop system components such as Oracle Internet Directory by executing the following command:

ORACLE_INSTANCE/bin/opmnctl stopall

8.14.2 Oracle Virtual Directory

Starting

Start system components such as Oracle Virtual Directory by typing:

ORACLE_INSTANCE/bin/opmnctl startall

You can verify that the system components have started by executing:

ORACLE_INSTANCE/bin/opmnctl status -l

Stopping

Stop system components such as Oracle Virtual Directory by executing the following command:

ORACLE_INSTANCE/bin/opmnctl stopall

8.14.3 Oracle HTTP Server

Prior to starting/stopping the Oracle HTTP server ensure that the environment variables ORACLE_HOME and ORACLE_INSTANCE are defined and that ORACLE_HOME/opmn/bin appears in the PATH. For example:

export ORACLE_HOME=/u01/app/oracle/product/fmw/web
export ORACLE_INSTANCE=/u01/app/oracle/admin/web[1-2]
export PATH=$ORACLE_HOME/opmn/bin:$PATH

Starting

Start the Oracle web tier by issuing the command:

opmnctl startall

Stop

Stop the web tier by issuing the command

opmnctl stopall

to stop the entire Web tier or

opmnctl stoproc process-type=OHS

to stop Oracle HTTP Server only.

Restarting

You can restart the web tier by issuing a Stop followed by a Start as described in the previous sections.

To restart the Oracle HTTP server only, use the following command.

opmnctl restartproc process-type=OHS

8.14.4 Node Manager

Start and stop the Node Manager as follows:

Starting

To start Node Manager, issue the commands:

IDMHOST> cd ORACLE_BASE/product/fmw/wlserver_10.3/server/bin
IDMHOST> ./startNodeManager.sh

Stopping

To stop node manager, kill the process started in the previous section

8.14.5 WebLogic Administration Server

Start and stop the WebLogic Administration Server as follows:

Starting

The recommended way to start the Administration Server is to use WLST and connect to Node Manager:

IDMHOST1> cd ORACLE_BASE/product/fmw/oracle_common/common/bin 
IDMHOST1> ./wlst.sh

Once in wlst shell, execute

wls:/offline>nmConnect(Admin_User,'Admin_Password,ADMINHOST1,'5556',
    'IDMDomain','/u01/app/oracle/admin/domain_name/aserver/IDMDomain'
wls:/nm/domain_name> nmStart('AdminServer')

Alternatively, you can start the Administration Server by using the command:

DOMAIN_HOME/bin/startWeblogic.sh

Stopping

To stop the Administration Server, log in to the WebLogic console using the URL: http://adminhost.mycompany.com:7001/console, where adminhost is the name of the host where the Administration Server is running.

Then proceed as follows:

Select Environment - Servers from the Domain Structure menu
Click on the Control tab
Select AdminServer(admin)
Click Shutdown and select Force Shutdown now.
Click Yes when asked to confirm that you wish to shutdown the administration server.

Restarting

Restart the server by following the Stop and Start procedures in the previous sections.

8.14.6 Oracle Identity Manager

Start and stop Oracle Identity Manager and Oracle SOA Suite servers as follows:

Starting

To start the Oracle Identity Manager managed server(s), log in to the WebLogic console using the URL: http://oimhost1.mycompany.com:7001/console.

Then proceed as follows:

Select Environment - Servers from the Domain Structure menu
Click on the Control tab
Select SOA Servers (WLS_SOA1 and/or WLS_SOA2)

Note:
You can start the Oracle Identity Manager and Oracle SOA Suite servers independently of each other. There is no dependency in their start order. However, the SOA server must be up and running for all of the OIM functionality to be available.
Click on the Start button.
Click Yes when asked to confirm that you wish to start the server(s).
After WLS_SOA1 and/or WLS_SOA2 have started, select WLS_OIM1 and/or WLS_OIM2
Click Start.
Click Yes when asked to confirm that you wish to start the server(s).

Stopping

To stop the OIM managed server(s), log in to the WebLogic console using the URL: http://oimhost1.mycompany.com:7001/console. Then proceed as follows:

Select Environment - Servers from the Domain Structure menu
Click the Control tab
Select OIM Servers (WLS_OIM1 and/or WLS_OIM2) and (WLS_SOA1 and/or WLS_SOA2)
Click the Shutdown button and select Force Shutdown now.
Click Yes when asked to confirm that you wish to shutdown the server(s).

Restarting

Restart the server by following the Stop and Start procedures in the previous sections.

8.14.7 Oracle Access Manager Managed Servers

Start and stop Oracle Access Manager managed servers as follows:

Starting

To start the OAM managed server(s), log in to the WebLogic console using the URL: http://oamhost1.mycompany.com:7001/console.

Then proceed as follows:

Select Environment - Servers from the Domain Structure menu
Click on the Control tab
Select OAM Servers (WLS_OAM1 and/or WLS_OAM2)
Click on the Start button.
Click Yes when asked to confirm that you wish to start the server(s).

Stopping

To stop the OAM managed server(s), log in to the WebLogic console using the URL: http://oamhost1.mycompany.com:7001/console. Then proceed as follows:

Select Environment - Servers from the Domain Structure menu
Click the Control tab
Select OAM Servers (WLS_OAM1 and/or WLS_OAM2)
Click the Shutdown button and select Force Shutdown now.
Click Yes when asked to confirm that you wish to shutdown the server(s).

Restarting

Restart the server by following the Stop and Start procedures in the previous sections.

8.14.8 Oracle Adaptive Access Manager Managed Servers

Start and stop Oracle Adaptive Access Manager as follows:

Starting

To start the OAAM managed server(s), log in to the WebLogic console using the URL: http://oaamhost1.mycompany.com:7001/console. Then proceed as follows:

Select Environment - Servers from the Domain Structure menu
Click the Control tab
Select OAAM Servers (WLS_OAAM1 and/or WLS_OAAM2)
Click the Start button.
Click Yes when asked to confirm that you wish to start the server(s).

Stopping

To stop the OAM managed server(s), log in to the WebLogic console using the URL: http://oaamhost1.mycompany.com:7001/console. Then proceed as follows:

Select Environment - Servers from the Domain Structure menu
Click the Control tab
Select OAAM Servers (WLS_OAAM1 and/or WLS_OAAM2)
Click Shutdown and select Force Shutdown now.
Click Yes when asked to confirm that you wish to shutdown the server(s).

Restarting

Restart the server by following the Stop and Start procedures above.

8.14.9 Oracle Identity Federation

Start and stop Oracle Identity Federation managed servers as follows:

Starting

To start the OIF managed server(s), log in to the WebLogic console at: http://oifhost1.mycompany.com:7001/console. Then proceed as follows:

Select Environment - Servers from the Domain Structure menu.
Click the Control tab.
Select OIF Servers (WLS_OIF1 and/or WLS_OIF2).
Click Start.
Click Yes when asked to confirm that you wish to start the server(s).

Stopping

To stop the OIF managed server(s), log in to the WebLogic console at: http://oifhost1.mycompany.com:7001/console. Then proceed as follows:

Select Environment - Servers from the Domain Structure menu.
Click the Control tab.
Select OIF Servers (WLS_OIF1 and/or WLS_OIF2).
Click Shutdown and select Force Shutdown now.
Click Yes when asked to confirm that you wish to shut down the server(s).

Restarting

Restart the server by following the Stop and Start procedures above.

Starting the OIF Instances and EMAgent

Start the OIF Instance and EMAgent by executing the following command:

ORACLE_INSTANCE/bin/opmnctl startall

You can verify that the instance started successfully by executing:

ORACLE_INSTANCE/bin/opmnctl status -l

Stopping the OIF Instances and EMAgent

Stop the OIF Instance and EMAgent by executing the following command:

ORACLE_INSTANCE/bin/opmnctl stopall

Footnote Legend

Footnote 1: The agent in use is specific to a deployment and different types of agents (with different features) can be used in a deployment.
Footnote 2: In addition to the built-in Credential Collector, Oracle Access Manager is capable of supporting external credential collectors.
Footnote 3: The credential collection will be different for non-username and password authentication schemes.
Footnote 4: Only WebGates support back channel communication.
Footnote 5: The agent may perform some housekeeping tasks, such as session refresh, before allowing the request to go through to the web resource.

8 Configuring High Availability for Identity Management Components

8.1 Identity Management Product Components and High Availability Concepts

8.1.1 About the 11g Oracle Identity Management Products

8.2 Prerequisites for Oracle Identity Management High Availability Configuration

8.2.1 Oracle Home Requirement

8.2.2 Database Prerequisites

8.2.3 Installing and Configuring the Database Repository

8.2.4 Obtaining the Repository Creation Utility Software

8.2.4.1 Executing the Repository Creation Utility

8.2.5 Configuring the Database for Oracle Fusion Middleware 11g Metadata

8.2.5.1 Database Examples in This Chapter

8.2.5.2 Database Services

8.2.5.3 Verifying Transparent Application Failover (TAF)

8.2.5.4 Configuring Virtual Server Names and Ports for the Load Balancer

8.2.5.4.1 Load Balancers

8.2.5.4.2 Virtual Server Names

8.3 Oracle Internet Directory High Availability

8.3.1 Oracle Internet Directory Component Architecture

8.3.1.1 Oracle Internet Directory Component Characteristics

8.3.1.1.1 Runtime Processes

8.3.1.1.2 Process Lifecycle

8.3.1.1.3 Request Flow

8.3.1.1.4 Configuration Artifacts

8.3.1.1.5 External Dependencies

8.3.1.1.6 Oracle Internet Directory Log File

8.3.2 Oracle Internet Directory High Availability Concepts

8.3.2.1 Oracle Internet Directory High Availability Architecture

8.3.2.1.1 Starting and Stopping the Cluster

8.3.2.1.2 Cluster-Wide Configuration Changes

8.3.2.2 Protection from Failures and Expected Behavior

8.3.2.2.1 Oracle Internet Directory Process Failure

8.3.2.2.2 Expected Client Application Behavior When Failure Occurs

8.3.2.2.3 External Dependency Failure

8.3.2.3 Oracle Internet Directory Prerequisites

8.3.2.3.1 Synchronizing the Time on Oracle Internet Directory Nodes

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

8.3.2.3.3 Load Balancer Virtual Server Names for Oracle Internet Directory

8.3.3 Oracle Internet Directory High Availability Configuration Steps

8.3.3.1 Installing Oracle Fusion Middleware Components

8.3.3.1.1 Install Oracle WebLogic Server

8.3.3.1.2 Installing Oracle Fusion Middleware for Identity Management

8.3.3.1.3 Upgrading Oracle Identity Management to Patch Set 3

8.3.3.2 Configuring Oracle Internet Directory Without a WebLogic Domain

8.3.3.2.1 Configuring Oracle Internet Directory on OIDHOST1

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

8.3.3.2.3 Configuring Oracle Internet Directory on OIDHOST2

8.3.3.2.4 Registering Oracle Internet Directory with a WebLogic Domain

8.3.3.3 Configuring Oracle Internet Directory With a WebLogic Domain

8.3.3.3.1 Configuring Oracle Internet Directory on OIDHOST1

8.3.3.3.2 Creating boot.properties for the Administration Server on OIDHOST1

8.3.3.3.3 Configuring Oracle Internet Directory on OIDHOST2

8.3.4 Validating Oracle Internet Directory High Availability

8.3.5 Oracle Internet Directory Failover and Expected Behavior

8.3.5.1 Performing an Oracle Internet Directory Failover

8.3.5.2 Performing an Oracle RAC Failover

8.3.6 Troubleshooting Oracle Internet Directory High Availability

8.3.7 Additional Oracle Internet Directory High Availability Issues

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

8.4 Oracle Virtual Directory High Availability

8.4.1 Oracle Virtual Directory Component Architecture

8.4.1.1 Oracle Virtual Directory Runtime Considerations

8.4.1.2 Oracle Virtual Directory Component Characteristics

8.4.1.2.1 Oracle Virtual Directory Log File

8.4.2 Oracle Virtual Directory High Availability Concepts

8.4.2.1 Oracle Virtual Directory High Availability Architecture

8.4.2.1.1 Oracle Virtual Directory High Availability Connect Features

8.4.2.2 Oracle Virtual Directory Prerequisites

8.4.2.2.1 Load Balancer Virtual Server Names for Oracle Virtual Directory

8.4.3 Oracle Virtual Directory High Availability Configuration Steps

8.4.3.1 Configuring Oracle Virtual Directory Without a WebLogic Domain

8.4.3.1.1 Configuring Oracle Virtual Directory on OVDHOST1

8.4.3.1.2 Configuring Oracle Virtual Directory on OVDHOST2

8.4.3.1.3 Registering Oracle Virtual Directory with a WebLogic Domain

8.4.3.2 Configuring Oracle Virtual Directory With a WebLogic Domain

8.4.3.2.1 Configuring Oracle Virtual Directory on OVDHOST1

8.4.3.2.2 Creating boot.properties for the Administration Server on OVDHOST1

8.4.3.2.3 Configuring Oracle Virtual Directory on OVDHOST2

8.4.3.3 Configuring Oracle Virtual Directory with Highly Available Data Sources

8.4.3.3.1 Configuring Oracle Virtual Directory with an Oracle RAC Database

8.4.3.3.2 Configuring Oracle Virtual Directory with LDAP

8.3.2.1.1 Starting and S topping the Cluster

8.3.7 Additional Oracle Inter net Directory High Availability Issues

8.5.2.1.1 Starti ng and Stopping the Cluster

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

8.5.3.1 Confi guring Oracle Directory Integration Platform and Oracle Directory Services Manager on IDMHOST1

8.5.3.3 Confi guring Oracle Directory Integration Platform and Oracle Directory Services Manager on IDMHOST2

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

8.6.2.1.1 Starti ng and Stopping the Cluster