16 Managing the Topology for an Enterprise Deployment

This chapter describes some operations that you can perform after you have set up the Identity Management topology. These operations include monitoring, scaling, backing up your topology, and troubleshooting.

This chapter includes the following topics:

16.1 Starting and Stopping Oracle Identity Management Components

This section describes how to start, stop and restart the various components of the Oracle Enterprise Deployment for Identity Management.

This section contains the following topics:

16.1.1 Startup Order

When starting up your entire infrastructure, start the components in the following order, (ignoring those not in your topology):

  1. Database(s)

  2. Database Listener(s)

  3. Oracle Unified Directory

  4. Node Manager

  5. Oracle Access Manager Server(s)

  6. WebLogic Administration Server

  7. Oracle Traffic Director

  8. SOA Server(s)

  9. Oracle Identity Manager Server(s)

16.1.2 Starting and Stopping Oracle Unified Directory

Start and stop Oracle Unified Directory as follows:

16.1.2.1 Starting Oracle Unified Directory

To start Oracle Unified Directory issue the following command:

OUD_ORACLE_INSTANCE/OUD/bin/start-ds

16.1.2.2 Stopping Oracle Unified Directory

To stop Oracle Unified Directory issue the command:

OUD_ORACLE_INSTANCE/OUD/bin/stop-ds

16.1.3 Starting, Stopping, and Restarting Access Manager Managed Servers

Start and stop Oracle Access Manager Managed Servers as follows:

16.1.3.1 Starting an Access Manager Managed Server When None is Running

Normally, you start Access Manager managed servers by using the WebLogic console. After you have enabled Single Sign-On for the administration consoles, however, you must have at least one Access Manager Server running in order to access a console. If no Access Manager server is running, you can start one by using WLST.

To invoke WLST on Linux or UNIX, type:

cd ORACLE_COMMON_HOME/common/bin
./wlst.sh

Once you are in the WLST shell, execute the following commands:

nmConnect('Admin_User','Admin_Password', 'OAMHOST','Port',  'domain_name','MSERVER_HOME')
nmStart('OAMServer')

where Port is NMGR_PORT in Section A.3, domain_name is the name of the domain and Admin_User and Admin_Password are the Node Manager username and password you entered in Step 2 of Section 9.5.4, "Updating Node Manager Credentials." For example:

nmConnect('weblogic','password', 'IDMHOST1','5556',  'IDMDomain','MSERVER_HOME')
nmStart('WLS_OAM1')

16.1.3.2 Starting an Access Manager Managed Server When Another is Running

To start an Oracle Access Manager managed server when you already have another one running, log in to the WebLogic console using the URL listed in Section 16.2, "About Identity Management Console URLs."

Then proceed as follows:

  1. Select Environment - Servers from the Domain Structure menu.

  2. Click the Control tab.

  3. Select OAM Servers (WLS_OAM1 and/or WLS_OAM2).

  4. Click the Start button.

  5. Click Yes when asked to confirm that you want to start the server(s).

16.1.3.3 Stopping Access Manager Managed Servers

To stop the Oracle Access Manager Managed Server(s), log in to the WebLogic console using the URL listed in Section 16.2, "About Identity Management Console URLs." Then proceed as follows:

  1. Select Environment - Servers from the Domain Structure menu.

  2. Click the Control tab.

  3. Select OAM Servers (WLS_OAM1 and/or WLS_OAM2).

  4. Click the Shutdown button and select Force Shutdown now.

  5. Click Yes when asked to confirm that you want to shut down the server(s).

16.1.3.4 Restarting Access Manager Managed Servers

Restart the server by following the Stop and Start procedures in the previous sections.

16.1.4 Starting, Stopping, and Restarting WebLogic Administration Server

Start and stop the WebLogic Administration Server as described in the following sections.

Note:

Admin_User and Admin_Password are only used to authenticate connections between Node Manager and clients. They are independent from the server administration ID and password and are stored in the ASERVER_HOME/config/nodemanager/nm_password.properties file.

16.1.4.1 Starting WebLogic Administration Server

The recommended way to start the Administration server is to use WLST and connect to Node Manager:

cd ORACLE_COMMON_HOME/common/bin
./wlst.sh

Once in WLST shell, execute

nmConnect('Admin_User','Admin_Password','ADMINVHN','5556', 'IDMDomain','ASERVER_HOME')
nmStart('AdminServer')

Alternatively, you can start the Administration server by using the command:

ASERVER_HOME/bin/startWebLogic.sh

16.1.4.2 Stopping WebLogic Administration Server

To stop the Administration Server, log in to the WebLogic console using the URL listed in Section 16.2, "About Identity Management Console URLs."

Then proceed as follows:

  1. Select Environment - Servers from the Domain Structure menu.

  2. Click the Control tab.

  3. Select AdminServer(admin).

  4. Click Shutdown and select Force Shutdown now.

  5. Click Yes when asked to confirm that you want to shut down the Administration Server.

16.1.4.3 Restarting WebLogic Administration Server

Restart the server by following the Stop and Start procedures in the previous sections.

16.1.5 Starting and Stopping Node Manager

Start and stop the Node Manager as follows:

16.1.5.1 Starting Node Manager

If the Node Manager being started is the one that controls the Administration Server (IDMHOST1 or IDMHOST2), then prior to starting the Node Manager issue the command:

export JAVA_OPTIONS=-DDomainRegistrationEnabled=true

If you are using shared storage for Node Manager, set JAVA_OPTIONS as described in Section 13.3.5, "Using a Common or Shared Storage Installation."

To start Node Manager, issue the commands:

cd /u02/private/oracle/config/nodemanager
./startNodeManager.sh

16.1.5.2 Stopping Node Manager

To stop Node Manager, kill the process started in the previous section.

16.1.5.3 Starting Node Manager for an Administration Server

cd /u02/private/oracle/config/nodemanager
export JAVA_OPTIONS=-DDomainRegistrationEnabled=true
./startNodeManager.sh

Note:

It is important to set -DDomainRegistrationEnabled=true whenever you start a Node Manager that manages the Administration Server.

16.1.6 Starting, Stopping, and Restarting Oracle Traffic Director

To start and stop Oracle Traffic Director instances see Section 7.6, "Starting the Oracle Traffic Director Instances."

16.1.7 Starting, Stopping, and Restarting Oracle Identity Manager

Start and stop Oracle Identity Manager and Oracle SOA Suite servers as follows:

16.1.7.1 Starting Oracle Identity Manager

To start the Oracle Identity Manager Managed Server(s), log in to the WebLogic console using the URL listed in Section 16.2, "About Identity Management Console URLs."

Then proceed as follows:

  1. Select Environment - Servers from the Domain Structure menu.

  2. Click the Control tab.

  3. 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 Oracle Identity Manager functionality to be available.

  4. Click the Start button.

  5. Click Yes when asked to confirm that you want to start the server(s).

  6. After WLS_SOA1 and/or WLS_SOA2 have started, select WLS_OIM1 and/or WLS_OIM2

  7. Click Start.

  8. Click Yes when asked to confirm that you want to start the server(s).

16.1.7.2 Stopping Oracle Identity Manager

To stop the Oracle Identity Manager Managed Server(s), log in to the WebLogic console using the URL listed in Section 16.2, "About Identity Management Console URLs." Then proceed as follows:

  1. Select Environment - Servers from the Domain Structure menu.

  2. Click the Control tab.

  3. Select OIM Servers (WLS_OIM1 and/or WLS_OIM2) and (WLS_SOA1 and/or WLS_SOA2).

  4. Click the Shutdown button and select Force Shutdown now.

  5. Click Yes when asked to confirm that you want to shutdown the server(s).

16.1.7.3 Restarting Oracle Identity Manager

Restart the server by following the Stop and Start procedures in the previous sections.

16.2 About Identity Management Console URLs

Table 16-1 lists the administration consoles used in this guide and their URLs.

Table 16-1 Console URLs

Domain Console URL

IDMDomain

WebLogic Administration Console

http://admin.mycompany.com/console
 

Enterprise Manager FMW Control

http://admin.mycompany.com/em
 

OAM Console

http://admin.mycompany.com/oamconsole
 

OIM Console

https:sso.mycompany.com/identity
 

ODSM

http://admin.mycompany.com/odsm

16.3 Monitoring Enterprise Deployments

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

This section contains the following topics:

16.3.1 Monitoring WebLogic Managed Servers

You can use Oracle Enterprise Manager Fusion Middleware Control to monitor Managed Servers and other Fusion Middleware components, such as Access Manager, Oracle Identity Manager, nd SOA. For more information, see the administrator guides listed in the Preface under "Related Documents".

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

This section contains the following topics:

16.4.1 Scaling Up the Topology

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

You cannot scale up the Web tier because you cannot have two Oracle Traffic Director instances on same compute node with the same configuration name.

16.4.1.1 Scaling Up Oracle Unified Directory

The directory tier has two Oracle Unified Directory nodes, IDMHOST1 and IDMHOST2, each running an Oracle Unified Directory instance. The Oracle Unified Directory binaries on either node can be used for creating the new Oracle Unified Directory instance.

To add a new Oracle Unified Directory instance to either Oracle Unified Directory host, follow the steps in Section 8.4.3, "Configuring an Additional Oracle Unified Directory Instance on IDMHOST2." with the following variations:

  • In Step 2 and Step 4, choose ports other than 1389, 1636, or 4444, as those ports are being used by the existing Oracle Unified Directory instance on the node.

  • Use the location for the new Oracle Unified Directory instance as the value for ORACLE_INSTANCE.

  • Reconfigure the load balancer with the host and port information of the new Oracle Unified Directory instance.

16.4.1.2 Scaling Up the Application Tier

The application tier consists of several nodes in pairs, depending on the products installed. These application servers run WebLogic Managed servers.

If you add a new managed server, after adding the managed server you must update your Oracle Traffic Director configuration.

To update Oracle Traffic Director for a new managed server:

  1. Log into the Oracle Traffic Director Administration Console.

  2. Click Server Pools on the left panel.

  3. Click the oam-pool.

  4. On the left panel, click New Origin Server.

  5. Add the IDMHOST3, 14100 of the Origin Server and click Next.

  6. Click New Origin Server, and then Close.

  7. Click Deploy Changes on the top of the panel.

16.4.1.2.1 Scaling Up Oracle Access Manager 11g

Scale up Oracle Access Manager as follows:

Log in to the Oracle WebLogic Server Administration Console at the URL listed in Section 16.2, "About Identity Management Console URLs."

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

  2. Click Lock & Edit from the Change Center menu.

  3. Select an existing server on the host you want to extend, for example: WLS_OAM1.

  4. Click Clone.

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

    • Server Listen Port: The port the new Managed Server uses. This port must be unique within the host.

  6. Click OK.

  7. Click the newly created server WLS_OAM3

  8. Click Save.

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

    If the source server from which the new one was cloned had already disabled host name verification, these steps are not required, as the host name 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.

  10. Click Activate configuration from the Change Center menu.

Register the new Managed Server with Oracle Access Manager. You now must configure the new Managed Server now as an Oracle Access Manager server. You do this from the Oracle OAM console. Proceed as follows:

  1. Log in to the OAM console as the oamadmin user. Use the URL listed in Section 16.2, "About Identity Management Console URLs."

  2. Click the System Configuration tab.

  3. Click Server Instances.

  4. Select Create from the Actions menu.

  5. Enter the following information:

    • Server Name: WLS_OAM3

    • Host: Host that the server runs on

    • Port: Listen port that was assigned when the Managed Server was created

    • OAM Proxy Port: Port you want the Oracle Access Manager proxy to run on. This is unique for the host

    • Proxy Server ID: AccessServerConfigProxy

    • Mode: Set to Open or Simple, depending on the mode your existing Oracle Access Manager servers are operating in.

  6. Click Coherence tab.

    Set Local Port to a unique value on the host.

  7. Click Apply.

  8. Restart the WebLogic Administration Server as described in Section 16.1, "Starting and Stopping Oracle Identity Management Components."

Add the newly created Oracle Access Manager server to all WebGate Profiles that might be using it, such as Webgate_IDM and IAMSuiteAgent

For example, to add the Oracle Access Manager server to Webgate_IDM, access the OAM console at the URL listed in Section 16.2, "About Identity Management Console URLs." Then proceed as follows:

  1. Log in as the Oracle Access Manager Admin User you created in Section 10.4, "Preparing the Identity Store."

  2. Click the System Configuration tab.

  3. Expand Access Manager Settings - SSO Agents - OAM Agents.

  4. Click the open folder icon, then click Search.

    You should see the WebGate agent Webgate_IDM.

  5. Click the agent Webgate_IDM.

  6. Select Edit from the Actions menu.

  7. Click + in the Primary Server list (or the Secondary Server list if this is a secondary server).

  8. Select the newly created managed server from the Server drop down list.

  9. Set Max Connections to 4.

  10. Click Apply.

Repeat Steps 5 through 10 for IAMSuiteAgent and all other WebGates that might be in use.

The procedures described in this section show you how to create a new managed server or directory instance. Add a third Instance in the Oracle Traffic Director OAM server pool:

To add a third instance to the Oracle Traffic Director OAM server pool:

  1. Log into the Oracle Traffic Director Administration Console.

  2. Click Server Pools on the left panel.

  3. Click the oam-pool.

  4. On the left panel, click New Origin Server.

  5. Add the IDMHOST3, 14100 of the Origin Server and click Next.

  6. Click New Origin Server, and then Close.

  7. Click Deploy Changes on the top of the panel.

You can now start the new Managed Server, as described in Section 16.1, "Starting and Stopping Oracle Identity Management Components."

16.4.1.2.2 Scaling Up Oracle Identity Manager (Adding Managed Servers to Existing Nodes)

In this case, you already have a node that runs a Managed Server configured with Oracle SOA Suite and Oracle Identity Manager components. The node contains a Middleware home, a SOA Oracle home, an Oracle Identity Manager Oracle home, 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 Oracle Identity and Access Management or Oracle SOA Suite binaries in a new location, or to run pack and unpack.

Follow these steps for scaling up the topology:

  1. Log in to the Administration Console at the URL listed in Section 16.2, "About Identity Management Console URLs." 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. From the Change Center menu, click Lock and Edit.

    3. Select the Managed Server that you want to clone (for example, WLS_OIM1 or WLS_SOA1).

    4. Select Clone.

    Name the new Managed Server WLS_OIMn or WLS_SOAn, where n is a number to identify the new Managed Server.

    The rest of the steps assume that you are adding a new server to IDMHOST1, which is already running WLS_SOA1 and WLS_OIM1.

  2. For the listen address, assign the host name or IP address 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.

  3. Create JMS Servers for SOA, Oracle Identity Manager, UMS, and BPM 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, as recommended in Section 4.3, "Shared Storage Recommendations for Enterprise Deployments."

      Note:

      This directory must exist before the Managed Server is started or the start operation fails.

      ASERVER_HOME/jms/SOAJMSFileStore_N

    2. Create a new JMS server for SOA, for example, SOAJMSServer_auto_N. Use the SOAJMSFileStore_N for this JMSServer. Target the SOAJMSServer_auto_N server to the recently created Managed Server (WLS_SOAn).

    3. Create a new JMS server for BPM, for example, BPMJMSServer_auto_N. Use the BPMJMSServer_auto_N for this JMSServer. Target the BPMJMSServer_auto_N server to the recently created Managed Server WLS_SOAn.

    4. Create a new persistence store for the new BPMJMSServer for example, BPMJMSFileStore_N. Specify the path for the store. This should be a directory on shared storage, as recommended in Section 4.3, "Shared Storage Recommendations for Enterprise Deployments."

    5. 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 as recommended in Section 4.3, "Shared Storage Recommendations for Enterprise Deployments."

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

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

    7. 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 as recommended in Section 4.3, "Shared Storage Recommendations for Enterprise Deployments."

      ASERVER_HOME/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 Oracle Identity Manager JMS Servers. For the purpose of clarity and isolation, individual persistent stores are used in the following steps.

    8. Create a new JMS Server for Oracle Identity Manager, for example, OIMJMSServer_N. Use the OIMJMSFileStore_N for this JMSServer. Target the OIMJMSServer_N server to the recently created Managed Server (WLS_OIMn).

    9. 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 Configuration Wizard JMS configuration for the first two servers (WLS_SOA1 and WLS_SOA2).

      Click the SOAJMSServerXXXXXX subdeployment. Add the new JMS Server for SOA called SOAJMSServer_N to this subdeployment. Click Save.

    10. 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 Configuration Wizard JMS configuration for the first two servers (WLS_SOA1 and WLS_SOA2).

      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 the BPMJMSSystemResource to include the recently created BPM 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 BPMJMSSystemResource (represented as a hyperlink in the Names column of the table). The Settings page for BPMJMSSystemResource appears. Click the SubDeployments tab. The subdeployment module for BPMJMS appears.

      Note:

      This subdeployment module name is a random name in the form of BPMJMSServerXXXXXX resulting from the Configuration Wizard JMS configuration for the first two servers (WLS_SOA1 and WLS_SOA2).

      Click the BPMJMSServerXXXXXX subdeployment. Add the new JMS Server for BPM called BPMJMSServer_N to this subdeployment. Click Save.

    12. Update the SubDeployment targets for OIMJMSModule to include the recently created Oracle Identity Manager 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 OIMJMSModule (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 Configuration Wizard JMS configuration for the first two servers (WLS_OIM1 and WLS_OIM2).

      Click the OIMJMSServerXXXXXX subdeployment. Add the new JMS Server for Oracle Identity Manager called OIMJMSServer_N to this subdeployment. Click Save.

  4. Configure Oracle Coherence, as described in Section 12.9, "Configuring Oracle Coherence for Deploying Composites."

  5. Configure TX persistent store for the new server. This should be a location visible from other nodes as indicated in the recommendations about shared storage.

    From the Administration Console, select the 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.

  6. 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 IDMHOSTn. If the source server from which the new one has been cloned had already disabled host name verification, these steps are not required (the host name 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.

  7. Repeat Steps 6a through 6h to disable host name verification for the WLS_OIMn Managed Servers. In Step d, select WLS_OIMn in the Names column of the table.

  8. Click Activate Changes from the Change Center menu.

  9. Update the SOA host and port using Oracle Enterprise Manager Fusion Middleware Control. Follow these steps:

    1. Open a browser and go to Oracle Enterprise Manager Fusion Middleware Control at the URL listed in Section 16.2, "About Identity Management Console URLs."

    2. Log in to Oracle Enterprise Manager Fusion Middleware Control using the Admin user credentials.

      Note:

      At least one of the Oracle Identity Manager Managed Servers must be running for when these steps are executed.

    3. Navigate to Identity and Access, and then oim.

    4. Right-click oim and navigate to System MBean Browser.

    5. Under Application Defined MBeans, navigate to oracle.iam, Application:oim, XMLConfig, Config, XMLConfig.SOAConfig, and then SOAConfig.

    6. Update the value for the Rmiurl attribute with the host and port of the new SOA server. Click Apply to save the changes.

    7. The Rmiurl attribute is used for accessing SOA EJBs deployed on SOA Managed Servers. This is the application server URL. The following is an example value for this attribute:

      cluster:t3://soa_cluster

  10. Restart the WebLogic Administration Server as described in Section 16.1, "Starting and Stopping Oracle Identity Management Components."

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

  12. Configure the newly created managed server for server migration. Follow the steps in Section 14.6, "Configuring Server Migration Targets" to configure server migration.

  13. 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 process ID (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 the floating IP address for WLS_SOA1 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.

16.4.1.3 Scaling Up Oracle Traffic Director

To scale up Oracle traffic director:

  1. Install Oracle Traffic Director on the new host as described in Section 7.2, "Installing Oracle Traffic Director on WEBHOST1 and WEBHOST2."

  2. Create a new instance of Oracle Traffic Director on the new host as described in Section 7.4, "Register WEBHOST2 with the Administration Node."

  3. Deploy the configuration to the new node by following the instructions in Section 7.10, "Deploying the Configuration and Testing the Virtual Server Addresses."

  4. Create a new failover group for the new Oracle Traffic Director instance as described in Section 7.11, "Creating a Failover Group for Virtual Hosts."

  5. Add the new Oracle Traffic Director failover group to the hardware load balancer pool.

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

This section contains the following topics:

16.4.2.1 Scaling Out the Web Tier

The procedures described in this section show you how to create a new managed server or directory instance. Add a third Instance in the Oracle Traffic Director OAM server pool:

To add a third instance to the Oracle Traffic Director OAM server pool:

  1. Log into the Oracle Traffic Director Administration Console.

  2. Click Server Pools on the left panel.

  3. Click the oam-pool.

  4. On the left panel, click New Origin Server.

  5. Add the IDMHOST3, 14100 of the Origin Server and click Next.

  6. Click New Orign Server, and then Close.

  7. Click Deploy Changes on the top of the panel.

16.4.2.2 Scaling Out the Application Tier

The application tier has two nodes (IDMHOST1 and IDMHOST2) running Managed Servers for Oracle Access Manager and Oracle Identity Manager.

Some of the procedures described in this section show you how to create a new WebLogic managed server on a third node. If you add a new managed server to your topology, after adding the managed server you must update your Oracle Traffic Director configuration files (on all nodes) and add the new server to the existing WebLogic cluster directives.

The procedures described in this section show you how to create a new managed server on a third node.

16.4.2.2.1 Scaling Out Oracle Access Manager 11g

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

Use the existing installations in shared storage for creating the new Managed Servers. You do not need to install WebLogic Server or Identity Management 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 you are using shared storage, allow the new host access to that shared storage area.

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

  2. To update the Middleware home list, create (or edit, if another WebLogic installation exists in the node) the IAM_MW_HOME/bea/beahomelist file and add IAM_MW_HOME/product/fmw to it.

  3. Log in to the Oracle WebLogic Server Administration Console at the URL listed in Section 16.2, "About Identity Management Console URLs."

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

  5. Click Lock & Edit from the Change Center menu.

  6. Select an existing server on the host you want to extend, for example: WLS_OAM1.

  7. Click Clone.

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

    • Server Listen Port: The port the new Managed Server uses. This port must be unique within the host.

  9. Click OK.

  10. Click the newly created server WLS_OAM3.

  11. Set the SSL listen port. This should be unique on the host that the Managed Server runs on.

  12. Click Save.

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

    If the source server from which the new one was cloned had already disabled host name verification, these steps are not required, as the host name 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.

  14. Click Activate Configuration from the Change Center menu.

  15. Restart the WebLogic Administration Server as described in Section 16.1, "Starting and Stopping Oracle Identity Management Components."

  16. Pack the domain on IDMHOST1 using the command:

    pack.sh -domain=ORACLE_BASE/config/domains/IDMDomain -template =/tmp/IDMDomain.jar -template_name="OAM Domain" -managed=true

    The pack.sh script is located in ORACLE_COMMON_HOME/common/bin.

  17. Unpack the domain on the new host using the command:

    unpack.sh -domain=MSERVER_HOME/IDMDomain -template=/tmp/IDMDomain.jar -app_dir=MSERVER_HOME/applications

    The unpack.sh script is located in ORACLE_COMMON_HOME/common/bin.

  18. Start Node Manager and update the property file.

    1. Start and stop Node Manager as described in Section 16.1, "Starting and Stopping Oracle Identity Management Components."

    2. Run the script setNMProps.sh, which is located in ORACLE_COMMON_HOME/common/bin, to update the node manager properties file, for example:

      cd ORACLE_COMMON_HOME/common/bin
./setNMProps.sh

    3. Start Node Manager once again as described in Section 16.1, "Starting and Stopping Oracle Identity Management Components."

Register the new Managed Server with Oracle Access Manager. The new Managed Server now must be configured as an Oracle Access Manager server. You do this from the Oracle OAM console, as follows:

  1. Log in to the OAM console as the oamadmin user. Use the URL listed in Section 16.2, "About Identity Management Console URLs."

  2. Click the System Configuration tab.

  3. Click Server Instances.

  4. Select Create from the Actions menu.

  5. Enter the following information:

    • Server Name: WLS_OAM3

    • Host: Host that the server is running on, IDMHOST3.

    • Port: Listen port that was assigned when the Managed Server was created.

    • OAM Proxy Port: Port you want the Oracle Access Manager proxy to run on. This is unique for the host.

    • Proxy Server ID: AccessServerConfigProxy

    • Mode: Set to Open or Simple, depending on the mode your existing Oracle Access Manager servers are operating in.

  6. Click Apply.

Add the newly created Oracle Access Manager server to all WebGate profiles that might be using it, such as Webgate_IDM and IAMSuiteAgent.

For example, to add the Oracle Access Manager server to Webgate_IDM, access the OAM console at the URL listed in Section 16.2, "About Identity Management Console URLs." Then proceed as follows:

  1. Log in as the Oracle Access Manager admin user you created in Section 10.4.3, "Configuring Oracle Unified Directory for Use with Oracle Access Manager and Oracle Identity Manager."

  2. Click the System Configuration tab.

  3. Expand Access Manager Settings - SSO Agents - OAM Agents.

  4. Click the open folder icon, then click Search.

    You should see the WebGate agent Webgate_IDM.

  5. Click the agent Webgate_IDM.

  6. Select Edit from the Actions menu.

  7. Click + in the Primary Server list (or the secondary server list if this is a secondary server).

  8. Select the newly created managed server from the Server drop down list.

  9. Set Max Connections to 4.

  10. Click Apply

Repeat Steps 5 through 10 for IAMSuiteAgent and other WebGates that are in use.

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

The procedures described in this section show you how to create a new managed server or directory instance. To configure the Web tier, add a third Instance in the Oracle Traffic Director OAM server pool:

To add a third instance to the Oracle Traffic Director OAM server pool:

  1. Log into the Oracle Traffic Director Administration Console.

  2. Click Server Pools on the left panel.

  3. Click the oam-pool.

  4. On the left panel, click New Origin Server.

  5. Add the IDMHOST3, 14100 of the Origin Server and click Next.

  6. Click New Origin Server, and then Close.

  7. Click Deploy Changes on the top of the panel.

16.4.2.2.2 Scaling Out Oracle Identity Manager (Adding Managed Servers to New Nodes)

When you scale out the topology, you add new Managed Servers configured with OIM and 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 OIM and SOA within the topology.

  • The new node can access the existing home directories for WebLogic Server, OIM, and SOA.

    Use the existing installations in shared storage for creating a new WLS_SOA or WLS_OIM Managed Server. You do not need to install WebLogic Server, OIM, 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.

    Notes:

    • If there is no existing installation in shared storage, installing WebLogic Server, IAM, and SOA in the new nodes is required as described in Section 12.9, "Configuring Oracle Coherence for Deploying Composites."

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

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

  1. On the new node, mount the existing Middleware home, which should include the Oracle Fusion Middleware 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.

  2. To attach ORACLE_BASE in shared storage to the local Oracle Inventory, execute the following command:

    cd IAM_MW_HOME/product/fmw/iam/oui/bin
/attachHome.sh -jreLoc JAVA_HOME

  3. To update the Middleware home list, create (or edit, if another WebLogic installation exists in the node) the IAM_MW_HOME/bea/beahomelist file and add IAM_MW_HOME/product/fmw to it.

  4. Log in to the Oracle WebLogic Administration Console at the URL listed in Section 16.2, "About Identity Management Console URLs."

  5. Create a new machine for the new node to be used, and add the machine to the domain.

  6. Update the machine's Node Manager's address to map the IP address of the node that is being used for scale out.

  7. Use the Oracle WebLogic Server Administration Console to clone the managed servers WLS_OIM and WLS_SOA1 into new Managed Servers. Name them WLS_SOAn and WLS_OIMn, respectively, 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.

  8. Assign the host names or IP addresses to the listen addresses of the new Managed Servers.

  9. If you are planning to use server migration for this server (which Oracle recommends) this should be the VIP address (also called a floating IP address) for the server. This VIP address should be different from the one used for the existing Managed Server.

  10. Create JMS servers for SOA, Oracle Identity Manager (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 as recommended in Section 4.3, "Shared Storage Recommendations for Enterprise Deployments." For example:

      ASERVER_HOME/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_auto_N. Use the SOAJMSFileStore_N for this JMSServer. Target the SOAJMSServer_auto_N Server to the recently created Managed Server (WLS_SOAn).

    3. Create a new persistence store for the new UMSJMSServer, and name it, for example, UMSJMSFileStore_N. Specify the path for the store. This should be a directory on shared storage as recommended in Section 4.3, "Shared Storage Recommendations for Enterprise Deployments."

      ASERVER_HOME/jms/UMSJMSFileStore_N

      Notes:

      • This directory must exist before the Managed Server is started or the start operation fails.

      • It is also possible to assign SOAJMSFileStore_N as the 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 JMS server. Target the UMSJMSServer_N server to the recently created Managed Server (WLS_SOAn).

    5. Create a new persistence store for the new BPMJMSServer, and name it, for example, BPMJMSFileStore_N. Specify the path for the store. This should be a directory on shared storage as recommended in Section 4.3, "Shared Storage Recommendations for Enterprise Deployments."

      ASERVER_HOME/jms/BPMJMSFileStore_N

      Notes:

      • This directory must exist before the Managed Server is started. Otherwise, the start operation fails.

      • It is also possible to assign SOAJMSFileStore_N as the store for the new BPM 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 BPM, for example, BPMJMSServer_N. Use the BPMJMSFileStore_N for this JMS server. Target the BPMJMSServer_N server to the recently created Managed Server (WLS_SOAn).

    7. Create a new persistence store for the new OIMJMSServer, and name it, for example, OIMJMSFileStore_N. Specify the path for the store. This should be a directory on shared storage as recommended in Section 4.3, "Shared Storage Recommendations for Enterprise Deployments."

      ASERVER_HOME/jms/OIMJMSFileStore_N

      Notes:

      • This directory must exist before the Managed Server is started or the start operation fails.

      • It is also possible to assign SOAJMSFileStore_N as the store for the new Oracle Identity Manager JMS Servers. For the purpose of clarity and isolation, individual persistent stores are used in the following steps.

    8. Create a new JMS Server for Oracle Identity Manager: for example, OIMJMSServer_N. Use the OIMJMSFileStore_N for this JMS Server. Target the OIMJMSServer_N Server to the recently created Managed Server (WLS_OIMn).

    9. Update the SubDeployment targets for the BPMJMSSystemResource to include the recently created BPM 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 BPMJMSSystemResource (represented as a hyperlink in the Names column of the table). The Settings page for BPMJMSSystemResource appears. Click the SubDeployments tab. The subdeployment module for BPMJMS appears.

      Note:

      This subdeployment module name is a random name in the form of BPMJMSServerXXXXXX resulting from the Configuration Wizard JMS configuration for the first two servers (WLS_SOA1 and WLS_SOA2).

      Click the BPMJMSServerXXXXXX subdeployment. Add the new JMS Server for BPM called BPMJMSServer_N to this subdeployment. Click Save.

    10. 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. Open the SubDeployments tab. The subdeployment module for SOAJMS appears.

      Note:

      This subdeployment module name is a random name in the form of SOAJMSServer resulting from the Configuration Wizard JMS configuration for the first two servers (WLS_SOA1 and WLS_SOA2).

      Click the SOAJMSServerXXXXXX subdeployment. Add the new JMS Server for SOA called SOAJMSServer_N to this subdeployment. Click Save.

    11. Update the SubDeployment targets for 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. Open the SubDeployments tab. The subdeployment module for UMSJMS appears

      Note:

      This subdeployment module is a random name in the form of UMSJMSServerXXXXXX resulting from the Config Wizard JMS configuration for the first two servers (WLS_SOA1 and WLS_SOA2).

      Click the UMSJMSServerXXXXXX subdeployment. Add the new JMS Server for UMS called UMSJMSServer_N to this subdeployment. Click Save.

    12. Update the SubDeployment Targets for OIMJMSModule to include the recently created Oracle Identity Manager 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 OIMJMSModule (represented as a hyperlink in the Names column of the table). The Settings page for OIMJMSModule appears. Click the SubDeployments tab. The subdeployment module for OIMJMS appears.

      Note:

      This subdeployment module is a random name in the form of OIMJMSServerXXXXXX resulting from the Config Wizard JMS configuration for the first two servers (WLS_SOA1 and WLS_SOA2).

      Click the OIMJMSXXXXXX subdeployment. Add the new JMS Server for Oracle Identity Manager called OIMJMSServer_N to this subdeployment. Click Save.

  11. Click Activate Configuration from the Change Center menu.

  12. Run the pack command to create a template pack. Run it on IDMHOST1 if you are using a single domain or on IDMHOST1. Proceed as follows:

    cd ORACLE_COMMON_HOME/common/bin
./pack.sh -managed=true -domain=ASERVER_HOME -template=/templates/oim_domain.jar -template_name="OIM Domain"

    Run the scp command on IDMHOST1 to copy the template file created to IDMHOSTn. For example:

    scp /templates/oim_domain.jar IDMHOSTN:/templates/oim_domain.jar

    Run the unpack command on IDMHOSTn to unpack the template in the Managed Server domain directory as follows:

    cd ORACLE_COMMON_HOME/oracle_common/bin
./unpack.sh -domain=MSERVER_HOME -template=/templates/oim_domain.jar -app_dir=MSERVER_HOME/applications

  13. Configure Oracle Coherence, as described in Section 12.9, "Configuring Oracle Coherence for Deploying Composites."

  14. Update the SOA host and port using Oracle Enterprise Manager Fusion Middleware Control. Follow these steps:

    1. Open a browser and go to Oracle Enterprise Manager Fusion Middleware Control at the URL listed in Section 16.2, "About Identity Management Console URLs."

    2. Log in to Oracle Enterprise Manager Fusion Middleware Control using the admin user credentials.

      Note:

      At least one of the Oracle Identity Manager Managed Servers must be running for when these steps are executed.

    3. Navigate to Identity and Access, and then oim.

    4. Right-click oim and navigate to System MBean Browser.

    5. Under Application Defined MBeans, navigate to oracle.iam, Application:oim, XMLConfig, Config, XMLConfig.SOAConfig, and then SOAConfig.

    6. Update the value for the Rmiurl attribute with the host and port of the new SOA server. Click Apply to save the changes.

    7. The Rmiurl attribute is used for accessing SOA EJBs deployed on SOA Managed Servers. This is the application server URL. The following is an example value for this attribute:

      cluster:t3://soa_cluster

  15. Configure TX persistent store for the new server. This should be a location visible from other nodes as indicated in the recommendations about shared storage.

    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.

  16. Disable host name verification for the new Managed Server. Before starting and verifying the WLS_SOAn and WLS_OIMn 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 IDMHOSTn. If the source server from which the new one has been cloned had already disabled host name verification, these steps are not required (the host name verification setting is propagated to the cloned server).

    To disable host name verification for WLS_SOAn:

    1. Expand the Environment node in the Domain Structure window.

    2. In the Oracle Enterprise Manager Console, select Oracle WebLogic Server Administration Console.

    3. Click Servers. The Summary of Servers page appears.

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

    To disable host name verification for WLS_OIMn, repeat the same steps, but select WLS_OIMn in the Names column in Step d.

  17. Click Activate Configuration from the Change Center menu.

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

    WL_HOME/server/bin/startNodeManager new_node_ip

  19. Start and test the new Managed Server from the Oracle WebLogic Server Administration Console:

    1. Shut down all the existing Managed Servers in the cluster.

    2. Ensure that the newly created Managed Servers, WLS_SOAn and WLS_SOAn, are running.

    3. Access the applications on the newly created Managed Servers (http://vip:port/soa-infra and http://vip:port/oim). The applications should be functional.

  20. 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 an environment configured for server migration that includes netmask, interface, wlsifconfig script superuser privileges. The floating IP addresses for the new Managed Servers are already present in the new node.

    Configure server migration following these steps:

    1. Log in to the Administration Console.

    2. In the left pane, expand Environment and select Servers.

    3. Select the server (represented as hyperlink) for which you want to configure migration from the Names column of the table. The Setting 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 enable 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.

    9. Test server migration for the new servers WLS_SOAn and WLS_OIMn, as follows.

      1. Determine the PID of the WLS_SOAn Managed Server by typing

      ps -ef | grep WLS_SOAn

      2. From the node where you added the new server, abruptly stop the WLS_SOAn Managed Server by typing:

      kill -9 pid

      3. Watch the Node Manager Console. You should see a message indicating that floating IP address for WLS_SOA1 has been disabled.

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

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

      6. Repeat Steps 1-5 for WLS_OIMn.

16.5 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 are 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 16-1 is a high-level architectural diagram of the Oracle Fusion Middleware Audit Framework.

Figure 16-1 Audit Event Flow

Audit Event Flow
Description of "Figure 16-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 run-time, applications may call these APIs where appropriate to audit the necessary information about a particular event happening in the application code. The interface enables 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 enables 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 grow over time. 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 (Oracle 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 enable 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 are 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.

16.6 Backing Up the Oracle IDM Enterprise Deployment

Back up the topology before and after any configuration changes.

16.6.1 Backing Up the Database

Back up the database. This is a full database backup (either hot or cold) using Oracle Recovery Manager (recommended) or OS tools, such as tar for cold backups if possible.

16.6.2 Backing Up the Administration Server Domain Directory

Back up the Administration Server domain directory to save your domain configuration. The configuration files are located in the following directory:

ASERVER_HOME

To back up the Administration Server run the following command on IDMHOST1:

tar -cvpf edgdomainback.tar ASERVER_HOME

16.6.3 Backing Up the Web Tier

Backup the Web tier. The configuration files are located in the following directories:

WEB_ORACLE_ADMININSTANCE

To back up the Oracle Traffic Director Administration Server, run the following command on WEBHOST1:

tar -cvpf webasback.tar WEB_ORACLE_ADMININSTANCE

16.6.4 Backing up the Middleware Home

If a new install has modified the MW_HOME, back it up using the following command:

tar -cvpf mw_home.tar MW_HOME

16.7 Patching Enterprise Deployments

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

This section contains the following topics:

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

16.7.2 Patching Identity and Access Management

In a single domain topology, apply patches as follows:

IDMDomain MW_HOME

  • Common patches

  • Oracle Access Manager Patches

  • Oracle Identity Manager Patches

  • IDM Tool Patches

16.7.3 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 IDMHOST1 to IDMHOST2.

  2. Bring down the Oracle Unified Directory server on the host on which you are applying the patch (IDMHOST1).

  3. Apply the Oracle Unified Directory patch on the host.

  4. Start the Oracle Unified Directory server on the host.

  5. Test the patch.

  6. Route the traffic to IDMHOST1 again.

  7. Verify the applications are working properly.

  8. Route the LDAP traffic on IDMHOST2 to IDMHOST1.

  9. Bring down the Oracle Unified Directory server on the host on which you are applying the patch (IDMHOST2).

  10. Apply the patch or Oracle Unified Directory patch on the host.

  11. Start the Oracle Unified Directory server on the host.

  12. Test the patch.

  13. Route the traffic to both hosts on which the patch has been applied (IDMHOST1 and IDMHOST2).

16.8 Preventing Timeouts for SQL

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 (Oracle 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 Oracle RAC, set this parameter in all of the Oracle home directories.

16.9 Manually Failing Over the WebLogic Administration Server

This section discusses how to fail over the Administration Server to IDMHOST2 and how to fail it back to IDMHOST1.

The same procedure can be applied to each domain you have created.

This section contains the following topics:

16.9.1 Failing over the Administration Server to IDMHOST2

If a node fails, you can fail over the Administration Server to another node. This section describes how to fail over the Administration Server from IDMHOST1 to IDMHOST2.

Assumptions:

  • The Administration Server is configured to listen on ADMINVHN.mycompany.com, and not on ANY address. See Section 9.4, "Running the Configuration Wizard to Create a Domain."

  • The Administration Server is failed over from IDMHOST1 to IDMHOST2, and the two nodes have these IP addresses:

    • IDMHOST1: 192.168.20.3

    • IDMHOST2: 192.168.20.4

    • ADMINVHN: 10.10.30.1

      This is the Virtual IP address where the Administration Server is running, assigned to interface:index (for example, bond1:1), available in IDMHOST1 or IDMHOST2.

  • The domain directory where the Administration Server is running in IDMHOST1 is on a shared storage and is mounted also from IDMHOST2.

    Note:

    NM in IDMHOST2 does not control the domain at this point, since unpack/nmEnroll has not been run yet on IDMHOST2. But for the purpose of AdminServer failover and control of the AdminServer itself, Node Manager is fully functional

  • Oracle WebLogic Server and Oracle Fusion Middleware Components have been installed in IDMHOST2 as described in previous chapters. That is, the same path for IDM_ORACLE_HOME and MW_HOME that exists in IDMHOST1 is available in IDMHOST2.

The following procedure shows how to fail over the Administration Server to a different node, IDMHOST2.

  1. Stop the Administration Server as described in Section 16.1, "Starting and Stopping Oracle Identity Management Components."

  2. Migrate the IP address to the second node.

    1. Run the following command as root on IDMHOST1 (where x:y is the current interface used by ADMINVHN.mycompany.com):

      /sbin/ifconfig x:y down

      For example:

      /sbin/ifconfig bond1:1 down

    2. Run the following command on IDMHOST2:

      /sbin/ifconfig interface:index ADMINVHN netmask netmask

      For example:

      /sbin/ifconfig bond1:1 10.10.30.1 netmask 255.255.255.0

    Note:

    Ensure that the netmask and interface to be used match the available network configuration in IDMHOST2.

  3. Update routing tables by using arping, for example:

    /sbin/arping -b -A -c 3 -I bond0 10.10.30.1

16.9.2 Starting the Administration Server on IDMHOST2

Perform the following steps to start Node Manager on IDMHOST2.

  1. On IDMHOST1, un-mount the Administration Server domain directory. For example:

    umount /u01/oracle/config

  2. On IDMHOST2, mount the Administration Server domain directory. For example:

    mount /u01/oracle/config

  3. Start Node Manager by using the following commands:

    cd /u02/private/oracle/config/nodemanager
./startNodeManager.sh

  4. Stop the Node Manager by killing the Node Manager process.

    Note:

    Starting and stopping Node Manager at this point is only necessary the first time you run Node Manager. Starting and stopping it creates a property file from a predefined template. The next step adds properties to that property file.

  5. Run the setNMProps.sh script to set the StartScriptEnabled property to true before starting Node Manager:

    cd MW_HOME/oracle_common/common/bin
./setNMProps.sh

    Note:

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

  6. Start the Node Manager as described in Section 16.1, "Starting and Stopping Oracle Identity Management Components."

  7. Start the Administration Server on IDMHOST2.

    cd ORACLE_COMMON_HOME/common/bin
./wlst.sh

    Once in the WLST shell, execute the following commands:

    nmConnect('Admin_User','Admin_Password', 'IDMHOST2','5556', 'IDMDomain','ASERVER_HOME')
nmStart('AdminServer')

  8. Test that you can access the Administration Server on IDMHOST2 as follows:

    1. Ensure that you can access the Oracle WebLogic Server Administration Console at:

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

    2. Check that you can access and verify the status of components in the Oracle Enterprise Manager at: http://ADMINVHN.mycompany.com:7001/em.

16.9.3 Validating Access to IDMHOST2

  1. Test that you can access the Oracle WebLogic Server Administration Console at:

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

  2. Check that you can access and verify the status of components in the Oracle Enterprise Manager at:

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

16.9.4 Failing the Administration Server Back to IDMHOST1

This step checks that you can fail back the Administration Server, that is, stop it on IDMHOST2 and run it on IDMHOST1. To do this, migrate ADMINVHN back to IDMHOST1 node as described in the following steps.

  1. Ensure that the Administration Server is not running. If it is, stop it from the WebLogic console, or by running the command stopWeblogic.sh from ASERVER_HOME/bin.

  2. On IDMHOST2, un-mount the Administration Server domain directory. For example:

    umount /u01/oracle/config

  3. On IDMHOST1, mount the Administration Server domain directory. For example:

    mount /u01/oracle/config/IDMDomain/aserver/

  4. Disable the ADMINVHN.mycompany.com virtual IP address on IDMHOST2 and run the following command as root on IDMHOST2:

    /sbin/ifconfig x:y down

    where x:y is the current interface used by ADMINVHN.mycompany.com.

  5. Run the following command on IDMHOST1:

    /sbin/ifconfig interface:index 10.10.30.1 netmask 255.255.255.0

    Note:

    Ensure that the netmask and interface to be used match the available network configuration in IDMHOST1

  6. Update routing tables by using arping. Run the following command from IDMHOST1.

    /sbin/arping -b -A -c 3 -I interface 10.10.30.1

  7. If Node Manager is not already started on IDMHOST1, start it, as described in Section 16.1, "Starting and Stopping Oracle Identity Management Components."

  8. Start the Administration Server again on IDMHOST1.

    cd ORACLE_COMMON_HOME/common/bin
./wlst.sh

    Once in the WLST shell, execute

    nmConnect(Admin_User,'Admin_Pasword, IDMHOST1,'5556',
     'IDMDomain','/u01/oracle/config/domains/IDMDomain'
nmStart('AdminServer')

  9. Test that you can access the Oracle WebLogic Server Administration Console at:

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

  10. Check that you can access and verify the status of components in the Oracle Enterprise Manager at:

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

16.10 Troubleshooting

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

This section contains the following topics:

16.10.1 Troubleshooting Access Manager 11g

This section describes some common problems that can arise with Access Manager and the actions you can take to resolve the problem. It contains the following topics:

16.10.1.1 User Reaches the Maximum Allowed Number of Sessions

Problem

The Access Manager server displays an error message similar to this:

The user has already reached the maximum allowed number of sessions. Please close one of the existing sessions before trying to login again.

Solution

If users log in multiple times without logging out, they might overshoot the maximum number of configured sessions. You can modify the maximum number of configured sessions by using the OAM Administration Console.

To modify the configuration by using the OAM Administration Console, proceed as follows:

  1. Go to System Configuration -> Common Settings -> Session

  2. Increase the value in the Maximum Number of Sessions per User field to cover all concurrent login sessions expected for any user. The range of values for this field is from 1 to any number.

16.10.1.2 Policies Do Not Get Created When Oracle Access Manager is First Installed

Problem

The Administration Server takes a long time to start after configuring Oracle Access Manager.

Solution

Tune the OAM database. When the Administration Server first starts after configuring Oracle Access Manager, it creates a number of default policies in the database. If the database is distant or in need of tuning, this can take a significant amount of time.

Resources
Authentication Policies
   Protected Higher Level Policy
   Protected Lower Level Policy
   Publicl Policy
Authorization Policies
   Authorization Policies

If you do not see these items, the initial population has failed. Check the Administration Server log file for details.

16.10.1.3 You Are Not Prompted for Credentials After Accessing a Protected Resource

Problem

When you access a protected resource, Oracle Access Manager should prompt you for your user name and password. For example, after creating a simple HTML page and adding it as a resource, you should see credential entry screen.

Solution

If you do not see the credential entry screen, perform the following steps:

  1. Verify that Host Aliases for IDMDomain have been set. You should have aliases for IDMDomain:80, IDMDomain:Null:, admin.mycompany.com:80, and sso.mycompany.com:443.

  2. Verify that WebGate is installed.

  3. Verify that OBAccessClient.xml was copied from ASERVER_HOME/output to the WebGate Lib directory and that Oracle Traffic Director was restarted.

  4. When OBAccessClient.xml was first created, the file was not formatted. When the Oracle Traffic Director is restarted, reexamine the file to ensure that it is now formatted. Oracle Traffic Director gets a new version of the file from Oracle Access Manager when it first starts.

  5. Shut down the Oracle Access Manager servers and try to access the protected resource. You should see an error saying Oracle Access Manager servers are not available. If you do not see this error, re-install WebGate.

16.10.1.4 Cannot Log In to OAM Console

Problem

You cannot log in to the OAM Console. The Administration Server diagnostic log might contain an error message similar to this:

Caused by: oracle.security.idm.OperationFailureException:
oracle.security.am.common.jndi.ldap.PoolingException [Root exception is oracle.ucp.UniversalConnectionPoolException:
Invalid life cycle state.
 Check the status of the Universal Connection Pool]
         at
oracle.security.idm.providers.stdldap.UCPool.acquireConnection(UCPool.java:112)

Solution

Remove the /tmp/UCP* files and restart the Administration Server.

16.10.2 Troubleshooting Oracle Identity Manager

This section describes some common problems that can arise with Oracle Identity Manager and the actions you can take to resolve the problem. It contains the following topics:

16.10.2.1 java.io.FileNotFoundException When Running Oracle Identity Manager Configuration

Problem

When you run Oracle Identity Manager configuration, the error java.io.FileNotFoundException: soaconfigplan.xml (Permission denied) may appear and Oracle Identity Manager configuration might fail.

Solution

To workaround this issue:

  1. Delete the file /tmp/oaconfigplan.xml.

  2. Start the configuration again (IAM_ORACLE_HOME/bin/config.sh).

16.10.2.2 ResourceConnectionValidationxception When Creating User in Oracle Identity Manager

Problem

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

Solution

Despite this exception, the user is created correctly.

16.10.3 Troubleshooting Oracle SOA Suite

This section describes some common problems that can arise with Oracle SOA Suite and the actions you can take to resolve the problem. It contains the following topics:

16.10.3.1 Transaction Timeout Error

Problem: The following transaction timeout error appears in the log:

Internal Exception: java.sql.SQLException: Unexpected exception while enlisting
 XAConnection java.sql.SQLException: XA error: XAResource.XAER_NOTA start()
failed on resource 'SOADataSource_soaedg_domain': XAER_NOTA : The XID
is not valid

Solution: Check your transaction timeout settings, and be sure that the JTA transaction time out is less than the DataSource XA Transaction Timeout, which is less than the distributed_lock_timeout (at the database).

With the out of the box configuration, the SOA data sources do not set XA timeout to any value. The Set XA Transaction Timeout configuration parameter is unchecked in the WebLogic Server Administration Console. In this case, the data sources use the domain level JTA timeout which is set to 30. Also, the default distributed_lock_timeout value for the database is 60. As a result, the SOA configuration works correctly for any system where transactions are expected to have lower life expectancy than such values. Adjust these values according to the transaction times your specific operations are expected to take.

16.10.4 Using My Oracle Support for Additional Troubleshooting Information

You can use My Oracle Support (formerly MetaLink) to help resolve Oracle Fusion Middleware problems. My Oracle Support contains several useful troubleshooting resources, such as:

  • Knowledge base articles

  • Community forums and discussions

  • Patches and upgrades

  • Certification information

Note:

You can also use My Oracle Support to log a service request.

You can access My Oracle Support at https://support.oracle.com.

16.10.5 OIM Reconciliation Jobs Fail

OIM reconciliation jobs fail, or the following message is seen in the log files:

LDAP Error 53 : [LDAP: error code 53 - Full resync required. Reason: The provided cookie is older than the start of historical in the server for the replicated domain : dc=mycompany,dc=com
]]

This error is caused by Oracle Unified Directory not been written to for a certain amount of time, and the data in the OUD changelog cookie has expired.

Solution:

  1. Open a browser and go to the following location:

    https://admin.mycompany.com

  2. Log in a as xelsysadm using the XelsysadmUserPswd.

  3. Under System Management, click Scheduler.

  4. Under Search Scheduled Jobs, enter LDAP * (there is a space before *) and hit Enter.

  5. For each job in the search results, click on the job name on the left, then click Disable on the right.

    Do this for all jobs. If the job is already disabled do nothing.

  6. Run the following commands on OUDHOST1:

    cd OUD_ORACLE_INSTANCE/OUD/bin
./ldapsearch -h idmhost1 -p 1389 -D "cn=oudadmin" -b "" -s base "objectclass=*" lastExternalChangelogCookie

Password for user 'cn=oudadmin': <OudAdminPwd>
dn:
lastExternalChangelogCookie: dc=mycompany,dc=com:00000140c682473c263600000862;

    Copy the output string that follows lastExternalChangelogCookie:. This value is required in the next step. For example,

    dc=mycompany,dc=com:00000140c682473c263600000862;

    The Hex portion must be 28 chars long. If this value has more than one Hex portion then separate each 28char portion with a space. For example:

    dc=mycompany,dc=com:00000140c4ceb0c07a8d00000043 00000140c52bd0b9104200000042 00000140c52bd0ba17b9000002ac 00000140c3b290b076040000012c;

  7. Run each of the following LDAP reconciliation jobs once to reset the last change number.:

    • LDAP Role Delete Full Reconciliation

    • LDAP User Delete Full Reconciliation

    • LDAP Role Create and Update Full Reconciliation

    • LDAP User Create and Update Full Reconciliation

    • LDAP Role Hierarchy Full Reconciliation

    • LDAP Role Membership Full Reconciliation

    To run the jobs:

    1. Login to the OIM System Administration Console as the user xelsysadm.

    2. Under System Management, click Scheduler.

    3. Under Search Scheduled Jobs, enter LDAP * (there is a space before *) and hit Enter.

    4. Click on the job to be run.

    5. Set the parameter Last Change Number to the value obtained in step 6.

      For example:

      dc=mycompany,dc=com:00000140c4ceb0c07a8d00000043 00000140c52bd0b9104200000042 00000140c52bd0ba17b9000002ac 00000140c3b290b076040000012c;

    6. Click Run Now.

    7. Repeat for each of the jobs in the list at the beginning of this step.

  8. For each incremental recon job whose last changelog number has been reset, execute the job and check that the job now completes successfully.

  9. After the job runs successfully, re-enable periodic running of the jobs according to your requirements.

If the issue continues to occur, increase the cookie retention time to two months by running the following command on each OUD instance:

If, the error appears again after the incremental jobs have been re-enabled and run successfully ("Full resync required. Reason: The provided cookie is older..."), then increase the OUD cookie retention time. Although there is no hard and fast rule as to what this value should be, it should be long enough to avoid the issue, but small enough to avoid unnecessary resource consumption on OUD. One or two weeks should suffice; two week is given in the following example:

./dsconfig set-replication-server-prop --provider-name "Multimaster Synchronization" --set replication-purge-delay:2w -D cn=oudadmin --trustAll -p 4444 -h IDMHOST1
 
Password for user 'cn=oudadmin':  <OudAdminPswd>
Enter choice [f]: f

16.10.6 LDAP Reconciliation Jobs Fail with LDAP 32 - USER SEARCH BASE WAS CORRECT ON FILES

Problem: The system management console under IT resources, Directory, will contain a search base level above what it needs to be.

For example:

dc=com

Instead of:

dc=mycompany, dc=com

Solution:

Edit the adapters.os_xml file located in the following directory:

DOMAIN_HOME/config/fmwconfig/ovd/oim

Add the searchbase into <remoteBase> and <root>

***Changed IT Resource and applied the changes on sysadmin console to : dc=mycompany,dc=com

Go to the System Administration Console at the following URL:

http://ssomycompany.com/sysadmin

When prompted, enter your administration ID and password.

Got to Configuration, and then IT Resource.

In the Search field enter Directory Services and click Search.

Edit : dc=com to dc=mycompany,dc=com, and click Save.

If after you change the search base you see the following error:

INSUFFICIENT PRIVILEGES LDAP 50

Add the following ACI to the config.ldif file of both OUD servers.

ds-cfg-global-aci: (targetcontrol="1.2.840.113556.1.4.319") (version 3.0; acl "page read control access"; allow(read) userdn="ldap:///cn=oimLDAP,cn=systemids,dc=mycompany,dc=com";)