9 Managing Enterprise Deployments

This chapter provides information about managing the Identity Management enterprise deployment you have set up.

This chapter includes the following topics:

9.1 Monitoring Enterprise Deployments

This section provides information about monitoring the Identity Management enterprise deployment described in this manual.

9.1.1 Monitoring Oracle Internet Directory

You can use the Oracle Enterprise Manager Fusion Middleware Control to monitor Oracle Internet Directory, as follows:

  1. On the Farm home page for an Identity Management domain, view the Fusion Middleware pie chart. This chart shows the status of Oracle Fusion Middleware components. Green sections of the chart indicate components that are up and running properly, and red sections indicate components that are down.

  2. The Identity and Access section below the chart includes the name of each individual Oracle Internet Directory instance (for example, oid1, oid2), its status, host name, and CPU usage percentage. A green arrow in the Status column indicates that the instance is up and running properly, and a red arrow indicates the instance is down. Click the name of an individual Oracle Internet Directory instance to view the home page for that instance.

  3. The home page for an instance displays metrics for the instance such as performance, load, security, response, CPU utilization %, and memory utilization %.

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

9.1.2 Monitoring Oracle Virtual Directory

You can use the Oracle Enterprise Manager Fusion Middleware Control to monitor Oracle Virtual Directory, as follows:

  1. On the Farm home page for an Identity Management domain, view the Fusion Middleware pie chart. This chart shows the status of Oracle Fusion Middleware components. Green sections of the chart indicate components that are up and running properly, and red sections indicate components that are down.

  2. The Identity and Access section below the chart includes the name of each instance of the Oracle Virtual Directory application (for example, ovd1, ovd2), its status, and host name. A green arrow in the Status column indicates that the Oracle Virtual Directory instance is up and running properly, and a red arrow indicates the instance is down. Click the name of an individual Oracle Virtual Directory instance to view the home page for that instance.

  3. The home page for an instance displays metrics and configurations for the instance such as:

    • Oracle Virtual Directory status - A green arrow next to the Oracle Virtual Directory instance name at the top of the page indicates that the instance is up and running properly and a red arrow indicates that the instance is down.

    • Current Load - This indicates the current work load of this Oracle Virtual Directory instance. It includes three metrics: Open Connections, Distinct Connected Users, and Distinct Connected IP Addresses.

    • Average Response Time Metric - This displays the average time (in milliseconds) to complete an LDAP search request.

    • Operations Metric - This displays the average number of LDAP search requests finished per millisecond.

    • Listeners - This table lists the listeners configured for this Oracle Virtual Directory instance to provide services to clients.

    • Adapters - This table lists existing adapters configured with the Oracle Virtual Directory instance. Oracle Virtual Directory uses adapters to connect to different underlying data repositories.

    • Resource Usage - On the right hand side of the page, the CPU and memory utilization metrics are displayed to indicate the system resources consumed by the Oracle Virtual Directory instance.

9.1.3 Monitoring Oracle Directory Integration Platform

You can use the Oracle Enterprise Manager Fusion Middleware Control to monitor Oracle Directory Integration Platform, as follows:

  1. On the Farm home page for an Identity Management domain, view the Fusion Middleware pie chart. This chart shows the status of Oracle Fusion Middleware components. Green sections of the chart indicate components that are up and running properly, and red sections indicate components that are down.

  2. The Identity and Access section below the chart includes the name of each instance of the Oracle Directory Integration Platform application (all have the name DIP (11.1.1.1.0)), its status, and host name. Each Oracle Directory Integration Platform instance is deployed in a different Managed Server). A green arrow in the Status column indicates that the Oracle Directory Integration Platform instance is up and running properly, and a red arrow indicates the instance is down. Click the name of an individual Oracle Directory Integration Platform instance to view the home page for that instance.

  3. The home page for an instance displays metrics for the instance such as:

    • Oracle Directory Integration Platform status - A green arrow next to the Oracle Directory Integration Platform instance name at the top of the page indicates that the instance is up and running properly and a red arrow indicates that the instance is down.

    • DIP Component Status - This table includes these metrics:

      • Quartz Scheduler - This indicates whether tasks can be scheduled for synchronization or not. A green arrow indicates the scheduler is up and a red arrow indicates that the scheduler is down.

      • Mbeans - This indicates whether profile management is available to the user or not. A green arrow indicates profile management is available and a red arrow indicates profile management is unavailable.

    • Synchronization Profiles - This shows registered profiles and their execution status. In a high availability deployment, all the instances will show the same list of profiles.

    • Provisioning Profiles- This shows registered provisioning profiles and their execution status. In a high availability deployment, all the instances will show the same list of profiles.

    • Resource Usage - On the right hand side of the page, the CPU and memory utilization metrics are displayed to indicate the resource usage by the Oracle Directory Integration Platform instance.

9.1.4 Monitoring Oracle Access Manager

Oracle Enterprise Manager Grid Control can be used to perform monitoring of Oracle Access Manager. For details, see the "Identity Management" chapter of Oracle Enterprise Manager Concepts.

9.2 Auditing Identity Management

Oracle Fusion Middleware Audit Framework is a new service in Oracle Fusion Middleware 11g, designed to provide a centralized audit framework for the middleware family of products. The framework provides audit service for platform components such as Oracle Platform Security Services (OPSS) and Oracle Web Services. It also provides a framework for JavaEE applications, starting with Oracle's own JavaEE components. JavaEE applications will be able to create application-specific audit events. For non-JavaEE Oracle components in the middleware such as C or JavaSE components, the audit framework also provides an end-to-end structure similar to that for JavaEE applications.

Figure 9-1 is a high-level architectural diagram of the Oracle Fusion Middleware Audit Framework.

Figure 9-1 Audit Event Flow

Description of Figure 9-1 follows
Description of "Figure 9-1 Audit Event Flow"

The Oracle Fusion Middleware Audit Framework consists of the following key components:

  • Audit APIs

    These are APIs provided by the audit framework for any audit-aware components integrating with the Oracle Fusion Middleware Audit Framework. During runtime, applications may call these APIs where appropriate to audit the necessary information about a particular event happening in the application code. The interface allows applications to specify event details such as username and other attributes needed to provide the context of the event being audited.

  • Audit Events and Configuration

    The Oracle Fusion Middleware Audit Framework provides a set of generic events for convenient mapping to application audit events. Some of these include common events such as authentication. The framework also allows applications to define application-specific events.

    These event definitions and configurations are implemented as part of the audit service in Oracle Platform Security Services. Configurations can be updated through Enterprise Manager (UI) and WLST (command-line tool).

  • The Audit Bus-stop

    Bus-stops are local files containing audit data before they are pushed to the audit repository. In the event where no database repository is configured, these bus-stop files can be used as a file-based audit repository. The bus-stop files are simple text files that can be queried easily to look up specific audit events. When a DB-based repository is in place, the bus-stop acts as an intermediary between the component and the audit repository. The local files are periodically uploaded to the audit repository based on a configurable time interval.

  • Audit Loader

    As the name implies, audit loader loads the files from the audit bus-stop into the audit repository. In the case of platform and JavaEE application audit, the audit loader is started as part of the JavaEE container start-up. In the case of system components, the audit loader is a periodically spawned process.

  • Audit Repository

    Audit Repository contains a pre-defined Oracle Fusion Middleware Audit Framework schema, created by Repository Creation Utility (RCU). Once configured, all the audit loaders are aware of the repository and upload data to it periodically. The audit data in the audit repository is expected to be cumulative and will grow overtime. Ideally, this should not be an operational database used by any other applications - rather, it should be a standalone RDBMS used for audit purposes only. In a highly available configuration, Oracle recommends that you use an Oracle Real Application Clusters (RAC) database as the audit data store.

  • Oracle Business Intelligence Publisher

    The data in the audit repository is exposed through pre-defined reports in Oracle Business Intelligence Publisher. The reports allow users to drill down the audit data based on various criteria. For example:

    • Username

    • Time Range

    • Application Type

    • Execution Context Identifier (ECID)

For more introductory information for the Oracle Fusion Middleware Audit Framework, see the "Introduction to Oracle Fusion Middleware Audit Framework" chapter in the Oracle Fusion Middleware Security Guide.

For information on how to configure the repository for Oracle Fusion Middleware Audit Framework, see the "Configuring and Managing Auditing" chapter in the Oracle Fusion Middleware Security Guide.

The EDG topology does not include Oracle Fusion Middleware Audit Framework configuration. The ability to generate audit data to the bus-stop files and the configuration of the audit loader will be available once the products are installed. The main consideration is the audit database repository where the audit data is stored. Because of the volume and the historical nature of the audit data, it is strongly recommended that customers use a separate database from the operational store or stores being used for other middleware components.

9.3 Scaling Enterprise Deployments

The reference enterprise topology discussed in this manual is highly scalable. It can be scaled up and or scaled out. When the topology is scaled up, a new server instance is added to a node already running one or more server instances. When the topology is scaled out, new servers are added to new nodes.

9.3.1 Scaling Up the Topology

The Oracle Identity Management topology described in the guide has three tiers: the directory tier, application tier and web tier. The components in all the three tiers can be scaled up by adding a new server instance to a node that already has one or more server instances running.

9.3.1.1 Scaling Up the Directory Tier

The directory tier consists of the two Oracle Internet Directory nodes (OIDHOST1 and OIDHOST2), each running an Oracle Internet Directory instance and the two Oracle Virtual Directory nodes (OVDHOST1 and OVDHOST2), each running an Oracle Virtual Directory instance. The Oracle Internet Directory or Oracle Virtual Directory instances can be scaled up on one or both the nodes.

9.3.1.1.1 Scaling Up Oracle Internet Directory

The directory tier has two Oracle Internet Directory nodes (OIDHOST1 and OIDHOST2), each running an Oracle Internet Directory instance. The existing Oracle Identity Management binaries on either node can be used for creating the new Oracle Internet Directory instance.

To add a new Oracle Internet Directory instance to either Oracle Internet Directory node, follow the steps in Section 4.5.3, "Installing an Additional Oracle Internet Directory" with the following variations:

  1. In step 2 and step 4, choose ports other than 389 and 636 since these ports are being used by the existing Oracle Internet Directory instance on the node.

  2. In step 5, instead of running the Oracle Identity Management 11g Installer, use the Oracle Fusion Middleware 11g Identity Management Configuration Wizard since the ORACLE_HOME already exists. Run the config.sh script under the ORACLE_HOME/bin directory to bring up the configuration wizard and follow the remaining steps to add a new Oracle Internet Directory instance to the node.

  3. The screens in steps 6, 8, 9, 18, and 19 in Section 4.5.3, "Installing an Additional Oracle Internet Directory" are related to a new install and will not be shown since the ORACLE_HOME is being shared.

  4. Follow the steps in Section 4.5.4, "Registering Oracle Internet Directory with the WebLogic Server Domain" to register the new Oracle Internet Directory instance with the WebLogic Domain. Use the location for the new Oracle Internet Directory instance as the value for ORACLE_INSTANCE.

  5. Reconfigure the load balancer with the host and port information of the new Oracle Internet Directory instance.

9.3.1.1.2 Scaling Up Oracle Virtual Directory

The directory tier has two nodes (OVDHOST1 and OVDHOST2), each running an Oracle Virtual Directory instance. The existing Oracle Identity Management binaries on either node can be used for creating the new Oracle Virtual Directory instance.

To add a new Oracle Virtual Directory instance to either Oracle Virtual Directory node, follow the steps in Section 4.6.2, "Installing an Additional Oracle Virtual Directory" with the following variations:

  1. In step 2 and step 4, choose ports other than 6501 and 7501 since these ports are being used by the existing Oracle Virtual Directory instance on the node.

  2. In step 6, instead of running the Oracle Identity Management 11g Installer, use the Oracle Fusion Middleware 11g Identity Management Configuration Wizard since the ORACLE_HOME already exists. Run the config.sh script under the ORACLE_HOME/bin directory to bring up the configuration wizard and follow the remaining steps to add a new Oracle Virtual Directory instance to the node.

  3. The screens in steps 7, 9, 10, 16 and 17 in Section 4.6.2, "Installing an Additional Oracle Virtual Directory" are related to a new install and will not be shown since the ORACLE_HOME is being shared.

  4. Follow the steps in Section 4.6.3, "Registering Oracle Virtual Directory with the Oracle WebLogic Server Domain" to register the new Oracle Virtual Directory instance with the WebLogic Domain. Use the location for the new Oracle Virtual Directory instance as the value for ORACLE_INSTANCE.

  5. Reconfigure the load balancer with the host and port information of the new Oracle Virtual Directory instance.

9.3.1.2 Scaling Up the Application Tier

The application tier has two nodes (IDMHOST1 and IDMHOST2) running Managed Servers for Oracle Directory Integration Platform and Oracle Directory Services Manager, two nodes (OAMHOST1 and OAMHOST2) running the Oracle Access Manager Identity Server and Access Server, and an Administration node (OAMADMINHOST) running an instance of the Oracle Access Manager WebPass, Policy Manager, WebGate and Oracle HTTP Server.

9.3.1.2.1 Scaling Up Oracle Directory Integration Platform and Oracle Directory Services Manager

The application tier already has a node (IDMHOST2) running a Managed Server configured with Oracle Directory Integration Platform and Oracle Directory Services Manager components. The node contains a WebLogic Server home and an Oracle Fusion Middleware Identity Management Home on the local disk.

The existing installations (WebLogic Server home, Oracle Fusion Middleware home, and domain directories) can be used for creating a new Managed Server for the Oracle Oracle Directory Integration Platform and Oracle Directory Services Manager components.

Follow the steps in Section 5.2, "Expanding the DIP and ODSM Cluster" with the following variations to scale up the topology for Oracle Directory Integration Platform and Oracle Directory Services Manager:

  1. Use the Oracle Identity Management Configuration Assistant to scale up the topology. Run the config.sh script under the ORACLE_HOME/bin directory to bring up the configuration assistant.

  2. Reconfigure the Oracle HTTP Server module with the new Managed Server. Follow the instructions in Section 6.4, "Configuring Oracle HTTP Server with the Load Balancer" and Section 6.5, "Configuring Oracle HTTP Server for Virtual Hosts" to complete this task.

9.3.1.3 Scaling Up Oracle Access Manager

With Oracle Access Manager, the new server instances need to be installed under a separate ORACLE_HOME location. Sharing ORACLE_HOMEs between instances of Oracle Access Manager components is not supported.

To scale up the Identity Server, follow the instructions in Section 7.3.1.2, "Installing the Second Identity Server on OAMHOST2."

To scale up the Access Server, follow the instructions in Section 7.4.2.2, "Starting the Access Server Installation."

To scale up the WebPass, follow the instructions in Section 7.3.3, "Installing WebPass on OAMADMINHOST."

To scale up the WebGate, follow the instructions in Section 7.4.3, "Installing WebGate on OAMADMINHOST, WEBHOST1, and WEBHOST2."

9.3.1.4 Scaling Up the Web Tier

The web tier already has a node running an instance of the Oracle HTTP Server. The existing Oracle HTTP Server binaries can be used for creating the new Oracle HTTP Server instance. To scale up the Oracle HTTP Server, follow the steps in Section 6.2, "Installing Oracle HTTP Server on WEBHOST1 and WEBHOST2" with the following variations:

  1. Use the Oracle Fusion Middleware 11g Web Tier Utilities Configuration Wizard to scale up the topology. Run the config.sh script under the ORACLE_HOME/bin directory to bring up the configuration wizard and follow the remaining steps to create a new instance of the Oracle HTTP Server.

  2. Reconfigure the load balancer with the host and port information of the new Oracle HTTP Server instance.

9.3.2 Scaling Out the Topology

In scaling out a topology, new servers are added to new nodes. The components in all three tiers of the Oracle Identity Management topology described in this manual can be scaled out by adding a new server instance to a new node.

9.3.2.1 Scaling Out the Directory Tier

The directory tier consists of the two Oracle Internet Directory nodes (OIDHOST1 and OIDHOST2), each running an Oracle Internet Directory instance and the two Oracle Virtual Directory nodes (OVDHOST1 and OVDHOST2), each running an Oracle Virtual Directory instance. The Oracle Internet Directory or Oracle Virtual Directory instances can be scaled out by adding new nodes to the directory tier.

9.3.2.1.1 Scaling Out Oracle Internet Directory

The directory tier has two Oracle Internet Directory nodes (OIDHOST1 and OIDHOST2), each running an Oracle Internet Directory instance. The OID instances can be scaled out by adding a new node to the existing Oracle Internet Directory cluster. To scale out Oracle Internet Directory instances, follow these steps:

  1. Follow the steps in Section 4.5.3, "Installing an Additional Oracle Internet Directory" to add a new node running Oracle Internet Directory.

  2. Follow the steps in Section 4.5.4, "Registering Oracle Internet Directory with the WebLogic Server Domain" to register the new Oracle Internet Directory instance with the WebLogic domain.

  3. Reconfigure the load balancer with the host and port information of the new Oracle Internet Directory instance.

9.3.2.1.2 Scaling Out Oracle Virtual Directory

The directory tier has two nodes (OVDHOST1 and OVDHOST2), each running an Oracle Virtual Directory instance. Oracle Virtual Directory can be scaled out by adding a new node configured to run Oracle Virtual Directory to the directory tier. To scale out Oracle Virtual Directory instances, follow these steps:

  1. Follow the steps in Section 4.6.2, "Installing an Additional Oracle Virtual Directory" to add a new node running Oracle Virtual Directory.

  2. Follow the steps in Section 4.6.3, "Registering Oracle Virtual Directory with the Oracle WebLogic Server Domain" to register the new Oracle Virtual Directory instance with the WebLogic domain.

  3. Reconfigure the load balancer with the host and port information of the new Oracle Virtual Directory instance.

9.3.2.2 Scaling Out the Application Tier

The application tier has two nodes (IDMHOST1 and IDMHOST2) running Managed Servers for Oracle Directory Integration Platform and Oracle Directory Services Manager, two nodes (OAMHOST1 and OAMHOST2) running the Oracle Access Manager Identity Server and Access Server, and an Administration node (OAMADMINHOST) running an instance of the Oracle Access Manager WebPass, Policy Manager, WebGate and Oracle HTTP Server.

9.3.2.2.1 Scaling Out Oracle Directory Integration Platform and Oracle Directory Services Manager

The application tier has two nodes (IDMHOST1 and IDMHOST2) running a Managed Server configured with Oracle Directory Integration Platform and Oracle Directory Services Manager. The Oracle Directory Integration Platform and Oracle Directory Services Manager instances can be scaled out by adding a new node with a Managed Server to the existing cluster. To scale out DIP and ODSM instances, follow the steps below:

  1. Follow the steps in Section 5.2, "Expanding the DIP and ODSM Cluster" to scale out the Oracle Directory Integration Platform and Oracle Directory Services Manager instances in the topology.

  2. Reconfigure the Oracle HTTP Server module with the new Managed Server. See Section 6.6, "Configuring mod_wl_ohs for Oracle WebLogic Server Clusters" for the instructions to complete this task.

9.3.2.2.2 Scaling Out Oracle Access Manager

With Oracle Access Manager, the new server instances need to be installed under a separate ORACLE_HOME location. Sharing ORACLE_HOMEs between instances of Oracle Access Manager components is not supported.

To scale out the Identity Server, follow the instructions in Section 7.3.1.2, "Installing the Second Identity Server on OAMHOST2."

To scale out the Access Server, follow the instructions in Section 7.4.2.2, "Starting the Access Server Installation."

To scale out the WebPass, follow the instructions in Section 7.3.3, "Installing WebPass on OAMADMINHOST."

To scale out the WebGate, follow the instructions in Section 7.4.3, "Installing WebGate on OAMADMINHOST, WEBHOST1, and WEBHOST2."

9.3.2.3 Scaling Out the Web Tier

The web tier has two nodes each running an instance of the Oracle HTTP Server. The Oracle HTTP Server components can be scaled out by adding a new node configured to run Oracle HTTP Server to the web tier. To scale out Oracle HTTP Server, follow these steps:

  1. Follow the steps in Section 6.2, "Installing Oracle HTTP Server on WEBHOST1 and WEBHOST2" to scale out the Oracle HTTP Server instances in the topology.

  2. Reconfigure the load balancer with the host and port information of the new Oracle HTTP Server node.

9.4 Performing Backups and Recoveries

Table 9-1 shows the static artifacts to back up in the 11g Oracle Identity Management enterprise deployment.

Table 9-1 Static Artifacts to Back Up in the Identity Management Enterprise Deployment

Type Host Location Tier

Oracle Home (database)

RAC database hosts:

INFRADBHOST1

INFRADBHOST2

User Defined

Directory Tier

MW_HOME (OID)

OIDHOST1

OIDHOST2

MW HOME:

/u01/app/oracle/product/fmw

ORACLE HOME:

/u01/app/oracle/product/fmw/idm on both the OIDHOST1 and OIDHOST2

Directory Tier

MW_HOME (OVD)

OVDHOST1

OVDHOST2

MW HOME:

/u01/app/oracle/product/fmw

ORACLE HOME:

/u01/app/oracle/product/fmw/idm on both the OVDHOST1 and OVDHOST2

Directory Tier

MW_HOME (DIP, ODSM, Admin Server)

IDMHOST1

IDMHOST2

FMW HOME:

/u01/app/oracle/product/fmw

DIP/ODSM ORACLE HOME:

/u01/app/oracle/product/fmw/idm on both IDMHOST1 and IDMHOST2

ADMIN SERVER ORACLE HOME:

/u01/app/oracle/product/fmw/idm on both IDMHOST1 and IDMHOST2

Application Tier

MW_HOME (OHS)

WEBHOST1

WEBHOST2

MW HOME:

/u01/app/oracle/product/fmw

ORACLE HOME:

/u01/app/oracle/product/fmw/web on WEBHOST1

ORACLE HOME:

/u01/app/oracle/product/fmw/web on WEBHOST2

Web Tier

OAMADMINHOST (used for OAM administration)

OAMADMINHOST

MW HOME:

/u01/app/oracle/product/fmw

OHS ORACLE HOME:

/u01/app/oracle/product/fmw/web

WEBPASS HOME:

/u01/app/oracle/product/fmw/oam/webcomponents/identity

POLICY MANAGER HOME:

/u01/app/oracle/product/fmw/oam/webcomponents/access

WEBGATE HOME:

/u01/app/oracle/product/fmw/oam/webgate

Application Tier

OAM

OAMHOST1

OAMHOST2

ORACLE ACCESS MANAGER HOME:

/u01/app/oracle/product/fmw/oam

IDENTITY SERVER HOME:

/u01/app/oracle/product/fmw/oam/identity

ACCESS SERVER HOME:

/u01/app/oracle/product/fmw/oam/access

Application Tier

Install Related Files

Each host

OraInventory:

ORACLE_BASE/orainventory

/etc/oratab, /etc/oraInst.loc

user_home/bea/beahomelist (on hosts where WebLogic Server is installed)

Windows registry: (HKEY_LOCAL/MACHINE/Oracle)

Not applicable.


Table 9-2 shows the runtime artifacts to back up in the 11g Oracle Identity Management enterprise deployment:

Table 9-2 Runtime Artifacts to Back Up in the Identity Management Enterprise Deployments

Type Host Location Tier

DOMAIN HOME

IDMHOST1

IDMHOST2

ORACLE_BASE/admin/IDMDomain/aserver on both IDMHOST1 and IDMHOST2

Application Tier

Application Artifacts (ear and war files)

IDMHOST1

IDMHOST2

Look at all the deployments, including Oracle Directory Integration Platform and Oracle Directory Services Manager, through the WebLogic Server Administration Console to identity all the application artifacts.

Application Tier

INSTANCE HOME (OHS)

WEBHOST1

WEBHOST2

OHS INSTANCE HOME on WEBHOST1:

/u01/app/oracle/admin/ohs_inst1

OHS INSTANCE HOME on WEBHOST2:

/u01/app/oracle/admin/ohs_inst2

Web Tier

INSTANCE HOME (OHS)


OAMADMINHOST

OHS INSTANCE HOME on WEBHOST1:


/u01/app/oracle/admin/ohs_inst/oamAdmin_ohs

Application Tier

OID INSTANCE HOME


OIDHOST1
OIDHOST2

OID INSTANCE HOME on OIDHOST1:


/u01/app/oracle/admin/oid_inst1

OID INSTANCE HOME on OIDHOST2:


/u01/app/oracle/admin/oid_inst2

Directory Tier

OVD INSTANCE HOME

OVDHOST1

OVDHOST2

OVD INSTANCE HOME on OVDHOST1:

/u01/app/oracle/admin/ovd_inst1

OVD INSTANCE HOME on OVDHOST2:

/u01/app/oracle/admin/ovd_inst2

Directory Tier

RAC Databases

INFRADBHOST1

INFRADBHOST2

User defined

Directory Tier

OAM

OAMHOST1

OAMHOST2

OAMADMINHOST

All the configurations are within the respective home directories described in this table. There are no instance homes.

Application Tier


For more information on backup and recovery of Oracle Fusion Middleware components, see Oracle Fusion Middleware Administrator's Guide.

9.5 Patching Enterprise Deployments

This section describes how to patch an Oracle Fusion Middleware patch file and how to patch Oracle Identity Management components with minimal down time.

9.5.1 Patching an Oracle Fusion Middleware Source File

For information on patching an Oracle Fusion Middleware source file, see the Oracle Fusion Middleware Administrator's Guide.

9.5.2 Patching Identity Management Components

To patch Oracle Identity Management components with minimal down time, it is recommended that you follow these guidelines:

  1. Route the LDAP traffic from OIDHOST1 and OVDHOST1 to OIDHOST2 and OVDHOST2.

  2. Bring down the Oracle Internet Directory or Oracle Virtual Directory server on the host on which you are applying the patch (OIDHOST1 or OVDHOST1).

  3. Apply the Oracle Internet Directory patch or Oracle Virtual Directory patch on the host.

  4. Start the Oracle Internet Directory or Oracle Virtual Directory server on the host.

  5. Test the patch.

  6. Route the traffic to OIDHOST1 or OVDHOST1 again.

  7. Verify the applications are working properly.

  8. Route the LDAP traffic on OIDHOST2 and OVDHOST2 to OIDHOST1 and OVDHOST1.

  9. Bring down the Oracle Internet Directory or Oracle Virtual Directory server on the host on which you are applying the patch (OIDHOST2 or OVDHOST2).

  10. Apply the Oracle Internet Directory patch or Oracle Virtual Directory patch on the host.

  11. Start the Oracle Internet Directory or Oracle Virtual Directory server on the host.

  12. Test the patch.

  13. Route the traffic to both hosts on which the patch has been applied (OIDHOST1 and OIDHOST2, or OVDHOST1 and OVDHOST2).

9.6 Troubleshooting

This section describes how to troubleshoot common issues that can arise with the Identity Management enterprise deployment described in this manual.

9.6.1 Troubleshooting Oracle Internet Directory

This section describes some of the common problems that can arise with Oracle Internet Directory and the actions you can take to resolve the problem.

Problem

The Oracle Internet Directory server is not responsive. When the load balancing router is configured to send an ICMP message to the LDAP SSL port for monitoring, the Oracle Internet Directory server starting SSL negotiation sometimes hangs, and thus it is required that the load balancing router not use ICMP messages for monitoring the LDAP SSL port.

Solution

Use an alternative such as TCP or the LDAP protocol itself.

Also, monitoring the LDAP non-SSL port is sufficient to detect LDAP availability.

Problem

The SSO/LDAP Application connection is lost to Oracle Internet Directory server

Solution

Verify the load balancing router timeout and SSO/Application timeout configuration parameter. The SSO/LDAP application timeout value should be less than LBR IDLE time out.

Problem

The LDAP application is receiving LDAP Error 53 (DSA Unwilling to Perform). When one of the database nodes goes down during the middle of the LDAP transaction, the Oracle Internet Directory server sends error 53 to the LDAP client

Solution

To see why the Oracle Internet Directory database node went down, see the Oracle Internet Directory logs in this location:

ORACLE_INSTANCE/diagnostics/logs/OID/oidldapd01s*.log

Problem

Issues involving TNSNAMES.ORA, TAF configuration, and related issues.

Solution

See the Oracle Database High Availability Overview manual.

9.6.2 Troubleshooting Oracle Virtual Directory

This section describes some of the common problems that can arise with Oracle Virtual Directory and the actions you can take to resolve the problem:

Problem

The Oracle Virtual Directory server is not responsive. When the load balancing router is configured to send an ICMP message to the LDAP SSL port for monitoring, the Oracle Virtual Directory server starting SSL negotiation sometimes hangs, and thus it is required that the load balancing router not use ICMP messages for monitoring the LDAP SSL port.

Solution

Use an alternative such as TCP or the LDAP protocol itself.

Also, monitoring the LDAP non-SSL port is sufficient to detect LDAP availability.

Problem

The SSO/LDAP Application connection is lost to the Oracle Virtual Directory server.

Solution

Verify the load balancing router timeout and SSO/Application timeout configuration parameter. The SSO/LDAP application timeout value should be less than LBR IDLE time out.

Problem

Issues involving TNSNAMES.ORA, TAF configuration, and related issues.

Solution

See the Oracle Database High Availability Overview manual.

9.6.3 Troubleshooting Oracle Directory Integration Platform

This section describes some of the common problems that can arise with Oracle Directory Integration Platform and the actions you can take to resolve the problem.

Problem

The instance is not working properly.

Solution

Check the respective log of the instance. For example, if the instance deployed in wls_ods1 is not running, then check the wls_ods1-diagnostic.log file.

Problem

Exceptions similar to the following are seen in Managed Server log files running the Oracle Directory Integration Platform application during a RAC failover:

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]

Solution

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

9.6.4 Troubleshooting Oracle Directory Services Manager

This section describes some of the common problems that can arise with Oracle Directory Services Manager and the actions you can take to resolve the problem.

After you have logged into Oracle Directory Services Manager, you can connect to multiple directory instances from the same browser window.

Avoid using multiple windows of the same browser program to connect to different directories at the same time. Doing so can cause a Target unreachable error.

You can log into the same Oracle Directory Services Manager instance from different browser programs, such as Internet Explorer and Firefox, and connect each to a different directory instance.

If you change the browser language setting, you must update the session in order to use the new setting. To update the session, either disconnect the current server connection, refresh the browser page (either reenter the Oracle Directory Services Manager URL in the URL filed and press enter or press F5) and reconnect to the same server, or quit and restart the browser.

Problem

You attempt to invoke Oracle Directory Services Manager from Oracle Enterprise Manager Fusion Middleware Control by selecting Directory Services Manager from the Oracle Internet Directory menu in the Oracle Internet Directory target, then Data Browser, Schema, Security, or Advanced.

Oracle Directory Services Manager does not open. You might see an error message.

Solution

This is probably an installation problem. See Oracle Fusion Middleware Installation Guide for Oracle Identity Management.

Problem

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:

  1. Oracle Directory Services Manager is deployed in a High Availability active-active configuration using Oracle HTTP Server.

  2. Display an Oracle Directory Services Manager page using the Oracle HTTP Server name and port number.

  3. Make a connection to an Oracle Internet Directory server.

  4. Work with the Oracle Internet Directory server using the current Oracle Directory Services Manager Oracle HTTP Server host and port.

  5. Shut down one Managed Server at a time using the WebLogic Server Administration Console.

  6. Go back to the Oracle Directory Services Manager page and port, and the connection which was established earlier with Oracle Internet Directory.

  7. When you do, a message is displayed advising you to re-establish a new connection to the Oracle Directory Services Manager page.

Solution

If you encounter this problem, perform the following steps:

  1. In your web browser, exit the current Oracle Directory Services Manager page.

  2. Launch a new web browser page and specify the same Oracle Directory Services Manager Oracle HTTP Server name and port.

  3. Re-establish a new connection to the Oracle Internet Directory server you were working with earlier.

Problem

Oracle Directory Services Manager temporarily loses its connection to Oracle Internet Directory and displays the message LDAP Server is down.

Solution

In a High Availability configuration where Oracle Directory Services Manager is connected to Oracle Internet Directory through a load balancer, Oracle Directory Services Manager reports that the server is down during failover from one instance of Oracle Internet Directory to another. In other configurations, this message might indicate that Oracle Internet Directory has been shut down and restarted. In either case, the connection will be reestablished in less than a minute, and you will be able to continue without logging in again.

Problem

Oracle Directory Services Manager temporarily loses its connection to an Oracle Internet Directory instance that is using a RAC database. Oracle Directory Services Manager might display the message

LDAP error code 53 - Function not implemented.

Solution

This error can occur during failover of the Oracle Database that the Oracle Internet Directory instance is using. The connection will be reestablished in less than a minute, and you will be able to continue without logging in again.

Problem

You must perform the steps below to configure Oracle HTTP Server to route Oracle Directory Services Manager requests to multiple Oracle WebLogic Servers in a clustered Oracle WebLogic Server environment.

Solution

Perform these steps:

  1. Create a backup copy of the Oracle HTTP Server's httpd.conf file. The backup copy will provide a source to revert back to if you encounter problems after performing this procedure.

  2. Add the following text to the end of the Oracle HTTP Server's httpd.conf file and replace the variable placeholder values with the host names and Managed Server port numbers specific to your environment. Be sure to use the <Location /odsm/ > as the first line in the entry. Using <Location /odsm/faces > or <Location /odsm/faces/odsm.jspx > can distort the appearance of the Oracle Directory Services Manager interface.

    <Location /odsm/ >
    SetHandler weblogic-handler
    WebLogicCluster host-name-1:managed-server-port,host-name_2:managed_server_port
    </Location>
    
  3. Stop, then start the Oracle HTTP Server to activate the configuration change.

    Note:

    Oracle Directory Services Manager loses its connection and displays a session time-out message if the Oracle WebLogic Server in the cluster that it is connected to fails. Oracle Directory Services Manager requests will be routed to the secondary Oracle WebLogic Server in the cluster that you identified in the httpd.conf file after you log back in to Oracle Directory Services Manager.

Problem

Attempting to access Oracle Directory Services Manager using a web browser fails.

Solution

  • Verify the Oracle Virtual Directory server is running. The Oracle Virtual Directory server must be running to connect to it from Oracle Directory Services Manager.

  • Verify you entered the correct credentials in the Server, Port, User Name and Password fields. You can execute an ldapbind command against the target Oracle Virtual Directory server to verify the server, user name, and password credentials.

  • Verify you are using a supported browser. Oracle Directory Services Manager supports the following browsers:

    • Internet Explorer 7

    • Firefox 2.0.0.2 and 3.0

    • Safari 3.1.2 (desktop)

    • Google Chrome 0.2.149.30

      Note:

      While Oracle Directory Services Manager supports all of the preceding browsers, only Internet Explorer 7 and Firefox 2.0.0.2 are certified.

Problem

Oracle Directory Services Manager does not open after you attempt to invoke it from Oracle Enterprise Manager Fusion Middleware Control by selecting one of the options from the Directory Services Manager entry in the Oracle Virtual Directory menu in the Oracle Virtual Directory target.

Solution

This is probably an installation problem. See the Oracle Fusion Middleware Installation Guide for Oracle Identity Management.

Problem

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:

  1. Oracle Directory Services Manager is deployed in a High Availability active-active configuration using Oracle HTTP Server.

  2. Display an Oracle Directory Services Manager page using the Oracle HTTP Server name and port number.

  3. Make a connection to an Oracle Virtual Directory server.

  4. Work with the Oracle Virtual Directory server using the current Oracle Directory Services Manager Oracle HTTP Server host and port.

  5. Shut down one Managed Server at a time using the WebLogic Server Administration Console.

  6. Go back to the Oracle Directory Services Manager page and port, and the connection which was established earlier with Oracle Virtual Directory. When you do, a message is displayed advising you to re-establish a new connection to the Oracle Directory Services Manager page.

Solution

If you encounter this problem, perform the following steps:

  1. In your web browser, exit the current Oracle Directory Services Manager page.

  2. Launch a new web browser page and specify the same Oracle Directory Services Manager Oracle HTTP Server name and port.

  3. Re-establish a new connection to the Oracle Virtual Directory server you were working with earlier.

Problem

Oracle Directory Services Manager temporarily loses its connection to an Oracle Virtual Directory instance that is using an Oracle RAC Database. Oracle Directory Services Manager might display the message LDAP error code 53 - Function not implemented.

Solution

This error can occur during failover of the Oracle Database that the Oracle Virtual Directory instance is using. The connection will be reestablished in less than a minute, and you will be able to continue without logging in again.

9.6.5 Troubleshooting Oracle Access Manager

Most of the manuals in the Oracle Access Manager 10.1.4.3 documentation set include a Troubleshooting appendix.

For troubleshooting information about a particular Oracle Access Manager component or feature, refer to the appropriate manual in the Oracle Access Manager 10.1.4.3 documentation set. See the "Road Map to Manuals" section in the Oracle Access Manager Introduction manual for a description of each manual in the Oracle Access Manager documentation set.

9.6.5.1 User is Redirected to the Login Screen After Activating Some Administration Console Changes

Problem

After configuring Oracle HTTP Server and the load balancing router to access the Oracle WebLogic Administration console, some activation changes cause redirection to the login screen for the WebLogic Server Administration Console.

Solution

This is the result of the Administration Console tracking changes made to ports, channels, and security settings made using the Administration Console. For certain changes the Console may redirect the user's browser to the Administration Server's listen address. Activation is completed regardless of the redirection. It is not required to log in again; users can simply update the URL to the following and then access the Home page for the Administration Console directly:

admin.mycompany.com/console/console.portal

9.6.5.2 User is Redirected to the Administration Console's Home Page After Activating Some Changes

Problem

After configuring Oracle Access Manager, some activation changes cause redirection to the Administration Console Home page (instead of the context menu where the activation was performed).

Solution

This is expected when Oracle Access Manager single sign-on is configured and is a result of the redirections performed by the Administration Server. Activation is completed regardless of the redirection. If required, user should manually navigate again to the desired context menu.

9.6.5.3 OAM Configuration Tool Does Not Remove Invalid URLs

Problem

If the policy domain has an invalid or incorrect URL, running the OAM Configuration Tool with the correct URLs will not update the Policy Manager, even though the tool completes successfully.

Solution

The OAM Configuration Tool adds new URLs to an existing policy domain when run using an existing app_domain name. It does not remove any of the existing URLs. The Policy Manager Console must be used to remove any invalid URLs. Follow these steps to update the URLs in an existing policy domain:

  1. Access the Policy Manager Console using the following URL:

    http://hostname:port/access/oblix
    

    For example, enter the following URL in your web browser:

    http://oamadminhost.mycompany.com:7777/access/oblix
    
  2. When prompted, log in using the administrator user credentials.

  3. On the landing page, click the Policy Manager link.

  4. On the Policy Manager Console, click the My Policy Domains link.

  5. On the My Policy Domains page, click the link for the appropriate policy domain.

  6. On the Policy Domain page, select the Resources tab.

  7. On the Resources page, select the valid or incorrect URLs and delete them.

9.7 Other Recommendations

This section describes some other recommendations for the Oracle Identity Management enterprise deployment.

9.7.1 Preventing Timeouts for SQL*Net Connections

Most of the production deployment involves firewalls. Because database connections are made across firewalls, Oracle recommends that the firewall be configured so that the database connection is not timed out. For Oracle Real Application Clusters (RAC), the database connections are made on Oracle RAC VIPs and the database listener port. You must configure the firewall so it does not time out these connections. If such a configuration is not possible, set the SQLNET.EXPIRE_TIME=n parameter in the ORACLE_HOME/network/admin/sqlnet.ora file on the database server, where n is the time in minutes. Set this value to less than the known value of the timeout for the network device (that is, a firewall). For RAC, set this parameter in all of the Oracle home directories.