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

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

17.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. LDAP Directory Server

  4. Node Manager

  5. Oracle Access Manager Server(s)

  6. WebLogic Administration Server

  7. Oracle HTTP Server(s)

  8. SOA Server(s)

  9. Oracle Identity Manager Server(s)

17.1.2 Starting and Stopping Oracle Unified Directory

Start and stop Oracle Unified Directory as follows:

17.1.2.1 Starting Oracle Unified Directory

To start Oracle Unified Directory issue the following command:

OUD_ORACLE_INSTANCE/OUD/bin/start-ds

17.1.2.2 Stopping Oracle Unified Directory

To stop Oracle Unified Directory issue the command:

OUD_ORACLE_INSTANCE/OUD/bin/stop-ds

17.1.3 Starting, Stopping, and Restarting Access Manager Managed Servers

Start and stop Oracle Access Manager Managed Servers as follows:

17.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 B.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 8.5.5, "Updating the Node Manager Credentials." For example:

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

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

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

17.1.3.4 Restarting Access Manager Managed Servers

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

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

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

17.1.4.2 Stopping WebLogic Administration Server

To stop the Administration Server, log in to the WebLogic console using the URL listed in Section 17.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.

17.1.4.3 Restarting WebLogic Administration Server

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

17.1.5 Starting and Stopping Node Manager

Start and stop the Node Manager as follows:

17.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 IAM_MW_HOME/wlserver_10.3/server/bin
./startNodeManager.sh

17.1.5.2 Stopping Node Manager

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

17.1.5.3 Starting Node Manager for an Administration Server

cd WL_HOME/server/bin
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.

17.1.6 Starting, Stopping, and Restarting Oracle HTTP Server

Prior to starting/stopping the Oracle HTTP server ensure that the environment variables WEB_ORACLE_HOME and ORACLE_INSTANCE are defined and that ORACLE_HOME/opmn/bin appears in the PATH. For example:

export ORACLE_HOME=WEB_ORACLE_HOME
export ORACLE_INSTANCE=WEB_ORACLE_INSTANCE
export PATH=$ORACLE_HOME/opmn/bin:$PATH

17.1.6.1 Starting Oracle HTTP Server

Start the Oracle web tier by issuing the command:

opmnctl startall

17.1.6.2 Stopping Oracle HTTP Server

Stop the web tier by issuing the command

opmnctl stopall

to stop the entire Web tier or

opmnctl stoproc process-type=OHS

to stop Oracle HTTP Server only.

17.1.6.3 Restarting Oracle HTTP Server

You can restart the web tier by issuing a Stop followed by a Start as described in the previous sections.

To restart the Oracle HTTP server only, use the following command.

opmnctl restartproc process-type=OHS

17.1.7 Starting, Stopping, and Restarting Oracle Identity Manager

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

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

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

17.1.7.3 Restarting Oracle Identity Manager

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

17.2 About Identity Management Console URLs

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

Table 17-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
 

ODSM

http://ADMIN.mycompany.com/odsm

OIMDomain

OIM Console

https://SSO.mycompany.com/identity

OIMDomain

WebLogic Administration Console

http://OIMADMIN.mycompany.com/console

OIMDomain

Enterprise Manager FMW Control

http://OIMADMIN.mycompany.com/em

OIMDomain

Authorization Policy Manager

http://OIMADMIN.mycompany.com/apm

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

17.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, and SOA. For more information, see the administrator guides listed in the Preface under "Related Documents".

17.3.2 Monitoring Oracle Unified Directory

You can check the status of Oracle Unified Directory by issuing the command:

OUD_ORACLE_INSTANCE/OUD/bin/status

This command accesses the locally running Oracle Unified Directory instance and reports the status of the directory, including whether or not replication and LDAP or LDAPS is enabled.

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

17.4.1 Scaling Up the Topology

The Oracle Identity Management topology described in the guide has three tiers: the database 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.

The procedures described in this section show you how to create a new managed server or directory instance. If you add a new managed server, after adding the managed server you must update your Oracle HTTP Server configuration files (on all nodes) and add the new server to the existing WebLogic cluster directives.

For example if you add a new Oracle Access Manager server, you must update WEB_ORACLE_INSTANCE/config/OHS/component_name/moduleconf/sso_vh.conf to include the new managed server.

Update sso_vh.conf as follows:

<Location /oam>
   SetHandler weblogic-handler
   WebLogicCluster IDMHOST1.mycompany.com:14100,IDMHOST2.mycompany.com:14100,IDMHOST3.mycompany.com:14100
</Location>

Once you have updated sso_vh.conf, restart the Oracle HTTP server(s) as described in Section 17.1, "Starting and Stopping Oracle Identity Management Components." Oracle recommends that you do this sequentially to prevent loss of service.

This section contains the following topics:

17.4.1.1 Scaling Up Oracle Unified Directory

The directory 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 7.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 (LDAP_DIR_PORT), 1636 (LDAP_DIR_SSL_PORT), or 4444 (LDAP_DIR_ADMIN_PORT), 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.

17.4.1.2 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 17.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. Log in to 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 Changes from the Change Center menu.

Register the new Managed Server with Oracle Access Manager. You now must configure the new Managed Server 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 17.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.

    • Coherence Local Port: Set Local Port to a unique value on the host

  6. Click Apply.

  7. Restart the WebLogic Administration Server as described in Section 17.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 17.2, "About Identity Management Console URLs." Then proceed as follows:

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

  2. Click the System Configuration tab.

  3. Expand Access Manager - 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 list.

  9. Set Maximum Number of Connections to 10.

  10. Click Apply.

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

Update the Web Tier. Once 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.

You do this by updating the file sso_vh.conf on each of the web tiers. This file resides in the directory: WEB_ORACLE_INSTANCE/config/OHS/component_name/moduleconf.

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

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

to:

<Location /oam>
   SetHandler weblogic-handler
   WebLogicCluster IDMHOST1.mycompany.com:14100,IDMHOST2.mycompany.com:14100,IDMHOST1.mycompany.com:14101
</Location>

Save the file and restart the Oracle HTTP server, as described in Section 17.1, "Starting and Stopping Oracle Identity Management Components."

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

17.4.1.3 Scaling Up Oracle Identity Manager

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 17.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. You do this as follows:

    1. Log in to the WebLogic Administration Console and navigate to Services -> Messaging -> JMS Servers.

    2. Click New.

    3. Enter a value for Name, such as BPMJMSServer_auto_3.

    4. Click Create New File Store.

    5. Select FileStore from the list

    6. Click Next.

    7. Enter a value for Name, such as BPMJMSFileStore_auto_3

    8. Enter the following values:

      Target: The new server you are creating.

      Directory: ASERVER_HOME/jms/BPMJMSFileStore_auto_3

      Note:

      Ensure that the directory exists. If it does not, you will not be able to start WLS_OIM3 or WLS_SOA3.

    9. Click OK.

    10. When you are returned to the JMS Server screen, select the newly created file store from the list.

    11. Click Next.

    12. On the next screen set the Target to the server you are creating.

    13. Click Finish.

    Create the following JMS Queues depending on the managed server you are creating:

    Server JMS Server Name File Store Name Directory Target

    WLS_SOAn

    BPMJMSServer_auto_n

    BPMJMSFileStore_auto_n

    ASERVER_HOME/jms/BPMJMSFileStore_auto_n

    WLS_SOAn

    WLS_SOAn

    SOAJMSServer_auto_n

    SOAJMSFileStore_auto_n

    ASERVER_HOME/jms/SOAJMSFileStore_auto_n

    WLS_SOAn

    WLS_SOAn

    UMSJMSServer_auto_n

    UMSJMSFileStore_auto_n

    ASERVER_HOME/jms/UMSJMSFileStore_auto_n

    WLS_SOAn

    WLS_OIMn

    OIMJMSServer_auto_n

    OIMJMSFileStore_auto_n

    ASERVER_HOME/jms/OIMJMSFileStore_auto_n

    WLS_OIMn

    WLS_OIMn

    JRFWSAsyncJmsServer_auto_n

    JRFWSAsyncFileStore_auto_n

    ASERVER_HOME/jms/JRFWSAsyncFileStore_auto_n

    WLS_OIMn

  4. Add the newly created JMS Queues to the existing JMS Modules by performing the following steps:

    1. Log in to the WebLogic Administration Console

    2. Navigate to Services -> Messaging -> JMS Modules

    3. Click a JMSModule, such as SOAJMSModule

    4. Click the Sub Deployments tab.

    5. Click the listed sub deployment.

      Note:

      This subdeployment module name is a random name in the form of JMSServerNameXXXXXX resulting from the Configuration Wizard JMS configuration.

    6. Assign the newly created JMS server, for example SOAJMSServer_auto_3.

    7. Click Save.

    Perform this for each of the JMS modules listed in the following table:

    JMS Module JMS Server

    BPMJMSModule

    BPMJMSServer_auto_n

    JRFWSAsyncJmsModule

    JRFWSAsyncJmsServer_auto_n

    OIMJMSModule

    OIMJMSServer_auto_n

    SOAJMSModule

    SOAJMSServer_auto_n

    UMSJMSSystemResource

    UMSJMSServer_auto_n

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

    Note:

    Only the localhost field must be changed for the server. Replace the localhost with the listen address of the new server added:

  6. Reconfigure the JMS Adapter with the new server using the FactoryProperties field in the Administration Console. Click on the corresponding cell under the Property value and enter the following:

    java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;
java.naming.provider.url=t3://soahostvhn1:8001,soahos2tvhn1:8001;
java.naming.security.principal=weblogic;
java.naming.security.credentials=weblogic1

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

    1. Log in to the Oracle WebLogic Server Administration Console.

    2. Click Lock and Edit.

    3. In the Domain Structure window, expand the Environment node and then click the Servers node.

      The Summary of Servers page is displayed.

    4. Click the name of either the Oracle Identity Manager or the SOA server (represented as a hyperlink) in the Name column of the table.

    5. The Settings page for the selected server is displayed, and defaults to the Configuration tab.

    6. Open the Services sub tab.

    7. Under the Default Store section of the page, provide the path to the default persistent store on shared storage. The directory structure of the path is as follows:

      For Oracle Identity Manager Servers: ASERVER_HOME/tlogs

      For SOA Servers: ASERVER_HOME/tlogs

    8. Click Save and Activate.

  8. 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. Log in to 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.

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

  10. Add new server to Cluster Address List.

    1. In the WebLogic Administration Console, expand the Environment node in the Domain Structure window.

    2. Click Clusters. The Summary of Clusters page appears.

    3. Click on the cluster name oim_cluster. The Cluster Properties page is displayed.

    4. Add the new OIM managed server to the cluster address list.

    5. Click Save.

  11. Click Activate Changes from the Change Center menu.

  12. 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 17.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 when these steps are executed.

    3. Select Farm_IDMDomain –> Identity and Access –> OIM –> oim(11.1.2.0.0).

    4. Select System MBean Browser from the menu or right click to select it.

    5. Select Application defined Mbeans –> oracle.iam –> Server: WLS_OIM1 –> Application: oim –> XML Config –> Config –> XMLConfig.SOAConfig –> 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

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

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

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

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

17.4.1.4 Scaling Up Oracle HTTP Server

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 Chapter 10, "Installing and Configuring Oracle Web Tier for an Enterprise Deployment."

  1. Use the Oracle Fusion Middleware 11g Web Tier Utilities Configuration Wizard to scale up the topology, as described in Chapter 10, "Installing and Configuring Oracle Web Tier for an Enterprise Deployment."

  2. Copy all files created in ORACLE_INSTANCE/config/OHS/component/moduleconf from the existing web tier configuration to the new one.

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

17.4.2 Scaling Out the Topology

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

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

For example if you add a new Oracle Access Manager server, you must update WEB_ORACLE_INSTANCE/config/OHS/component_name/moduleconf/sso_vh.conf to include the new managed server.

Update sso_vh.conf as follows:

<Location /oam>
SetHandler weblogic-handler
WebLogicCluster
IDMHOST1.mycompany.com:14100,IDMHOST2.mycompany.com:14100,IDMHOST3.mycompany.com:14100
</Location>

Once you have updated sso_vh.conf, restart the Oracle HTTP server(s) as described in Section 17.1, "Starting and Stopping Oracle Identity Management Components." Oracle recommends that you do this sequentially to prevent loss of service.

This section contains the following topics:

17.4.2.1 Scaling Out Oracle Unified Directory

The directory has two Oracle Unified Directory nodes, IDMHOST1 and IDMHOST2, each running an Oracle Unified Directory instance. The Oracle Unified Directory instances can be scaled out by adding a new node to the configuration, as follows:

  1. Follow the steps in Section 7.3, "Installing Oracle Unified Directory" to install the OUD binaries on the new host.

  2. Follow the steps in Section 7.4.3, "Configuring an Additional Oracle Unified Directory Instance on IDMHOST2."

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

17.4.2.2 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 Identity and Access Management 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 17.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. Log in to 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 Changes from the Change Center menu.

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

  16. Pack the domain on IDMHOST1 using the command:

    pack.sh -domain=ASERVER_HOME -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 -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 17.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 17.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 17.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 17.2, "About Identity Management Console URLs." Then proceed as follows:

  1. Log in as the Oracle Access Manager admin user you created in Section 9.4, "Preparing the Identity Store."

  2. Click the System Configuration tab.

  3. Expand Access Manager - 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 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.

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

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

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

to:

<Location /oam>
   SetHandler weblogic-handler
   WebLogicCluster IDMHOST1.mycompany.com:14100,IDMHOST2.mycompany.com:14100,IDMHOST3.mycompany.com:14100
</Location>

17.4.2.3 Scaling Out Oracle Identity Manager

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 17.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_OIM1 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. Assign the managed server to the newly created machine.

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

  11. Create JMS Servers for SOA, Oracle Identity Manager, UMS, and BPM on the new Managed Server. You do this as follows:

    1. Log in to the WebLogic Administration Console and navigate to Services -> Messaging -> JMS Servers.

    2. Click New.

    3. Enter a value for Name, such as BPMJMSServer_auto_3.

    4. Click Create New File Store.

    5. Select FileStore from the list

    6. Click Next.

    7. Enter a value for Name, such as BPMJMSFileStore_3

    8. Enter the following values:

      Target: The new server you are creating.

      Directory: ASERVER_HOME/jms/BPMJMSFileStore_3

    9. Click OK.

    10. When you are returned to the JMS Server screen, select the newly created file store from the list.

    11. Click Next.

    12. On the next screen set the Target to the server you are creating.

    13. Click Finish.

    Create the following JMS Queues depending on the managed server you are creating:

    Server JMS Server Name File Store Name Directory Target

    WLS_SOAn

    BPMJMSServer_auto_n

    BPMJMSFileStore_n

    ASERVER_HOME/jms/BPMJMSFileStore_n

    WLS_SOAn

    WLS_SOAn

    SOAJMSServer_auto_n

    SOAJMSFileStore_n

    ASERVER_HOME/jms/SOAJMSFileStore_n

    WLS_SOAn

    WLS_SOAn

    UMSJMSServer_auto_n

    UMSJMSFileStore_n

    ASERVER_HOME/jms/UMSJMSFileStore_n

    WLS_SOAn

    WLS_OIMn

    OIMJMSServer_auto_n

    OIMJMSFileStore_n

    ASERVER_HOME/jms/OIMJMSFileStore_n

    WLS_OIMn

    WLS_OIMn

    JRFWSAsyncJmsServer_auto_n

    JRFWSAsyncJmsServer_n

    ASERVER_HOME/jms/JRFWSAsyncJmsServerJMSFileStore_n

    WLS_OIMn

  12. Add the newly created JMS Queues to the existing JMS Modules by performing the following steps:

    1. Log in to the WebLogic Administration Console

    2. Navigate to Services -> Messaging -> JMS Modules

    3. Click a JMSModule, such as SOAJMSModule

    4. Click the Sub Deployments tab.

    5. Click the listed sub deployment.

      Note:

      This subdeployment module name is a random name in the form of JMSServerNameXXXXXX resulting from the Configuration Wizard JMS configuration.

    6. Assign the newly created JMS server, for example SOAJMSServer_auto_3.

    7. Click Save.

    Perform this for each of the JMS modules listed in the following table:

    JMS Module JMS Server

    BPMJMSModule

    BPMJMSServer_auto_n

    JRFWSAsyncJmsModule

    JRFWSAsyncJmsServer_auto_n

    OIMJMSModule

    OIMJMSServer_auto_n

    SOAJMSModule

    SOAJMSServer_auto_n

    UMSJMSSystemResource

    UMSJMSServer_auto_n

  13. Click Activate Changes from the Change Center menu.

  14. Use the pack, scp, and unpack commands to create a backup of the domain. To do this perform the following steps:

    1. Run the pack command on IDMHOST1 to create a template:

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

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

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

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

    Note:

    Only the localhost field must be changed for the server. Replace the localhost with the listen address of the new server added:

  16. 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 17.2, "About Identity Management Console URLs."

    2. Log in to Oracle Enterprise Manager Fusion Middleware Control using the WebLogic adminsitration account weblogic_idm.

      Note:

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

    3. Select Farm_IDMDomain –> Identity and Access –> OIM –> oim(11.1.2.0.0).

    4. Select System MBean Browser from the menu or right click to select it.

    5. Select Application defined Mbeans –> oracle.iam –> Server: WLS_OIM1 –> Application: oim –> XML Config –> Config –> XMLConfig.SOAConfig –> 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

  17. Add new server to Cluster Address List.

    1. In the WebLogic Administration Console, expand the Environment node in the Domain Structure window.

    2. Click Clusters. The Summary of Clusters page appears.

    3. Click on the cluster name oim_cluster. The Cluster Properties page is displayed.

    4. Add the new OIM managed server to the cluster address list.

    5. Click Save.

    6. Repeat this step to add any new SOA managed servers to the soa_cluster address list.

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

  19. 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. Log in to 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.

  20. Click Activate Changes from the Change Center menu.

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

  22. 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_OIMn, 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.

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

17.4.2.4 Scaling Out the Oracle HTTP Server

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, proceed as follows:

  1. Follow the steps in Section 10.2.3, "Installing Oracle HTTP Server." Alternatively, on the new node, mount the existing Middleware home, if you are using shared storage.

  2. Follow the steps in Chapter 10, "Installing and Configuring Oracle Web Tier for an Enterprise Deployment."

  3. Copy all files created in WEB_ORACLE_INSTANCE/config/OHS/component_name/moduleconf from the existing web tier configuration to the new one.

  4. If you have enabled Single Sign-on in the topology, you must update the Web Tier configuration for Single Sign-on as described in Section 15.7, "Installing and Configuring WebGate 11g."

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

17.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 17-1 is a high-level architectural diagram of the Oracle Fusion Middleware Audit Framework. For more information, see Oracle Fusion Middleware Application Security Guide.

Figure 17-1 Audit Event Flow

Surrounding text describes Figure 17-1 .

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

17.6 Performing Backups and Recoveries

You can use the UNIX tar command for most backups. Typical usage is:

tar -cvpf BACKUP_LOCATION/backup_file.tar directories

You can use the UNIX tar command for recovery. Typical usage is:

tar -xvf BACKUP_LOCATION/backup_file.tar

For database backup and recovery, you can use the database utility RMAN. See the Oracle Database Backup and Recovery Reference for more information on using this command.

This section contains the following topics:

17.6.1 Performing Baseline Backups

Perform baseline backups when building a system and when applying patches that update static artifacts, such as the Oracle binaries.

After performing a baseline backup, also perform a runtime backup.

Table 17-2 Static Artifacts to Back Up in the Identity Management Enterprise Deployment

Type Location Type Comments

Database

ORACLE_HOME

Grid ORACLE_HOME

File Copy

See Oracle Database Backup and Recovery Reference for more information.

Middleware Homes

IAM_MW_HOME

OIM_MW_HOMEFoot 1 

DIR_MW_HOMEFoot 2 

File Copy

Located on shared storage, so only requires backup from one host.

Web Middleware Home

Middleware Home: WEB_MW_HOME

File Copy

Located on local storage. Back up each WEBHOST individually.

Install Related

ORACLE_BASE/orainventory

/etc/oratab, /etc/oraInst.loc

HOME/bea/beahomelist

File Copy

Located on local storage. Back up each host individually.

Load Balancer

  

File Copy

Back up the load balancer configuration. See your vendor documentation.

Servers

    

Back up the operating systems. See your vendor documentation.

Footnote 1 Split domain only

Footnote 2 Middleware home of your Oracle Internet Directory or Oracle Virtual Directory Installation. Installation and configuration of Oracle Identity Management is not covered in this Guide.

Note:

It is also recommended that you back up your load balancer configuration. Refer to your vendor documentation on how to do this.

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

17.6.2 Performing Runtime Backups

Perform runtime backups on an ongoing basis. These backups contain information on items that can change frequently, such as data in the database, domain configuration information, and identity information in LDAP directories.

Table 17-3 Run-Time Artifacts to Back Up in the Identity Management Enterprise Deployments

Type Location Type Comments

Database

Data

RMAN

See Oracle Database Backup and Recovery Reference for more information.

Oracle Unified Directory

OUD_ORACLE_INSTANCE

Oracle Unified Directory data

File Copy

Oracle Unified Directory backup

Located on local storage. Back up each LDAPHOST individually.

See Oracle Fusion Middleware Administrator's Guide for Oracle Unified Directory for more information.

When performing a cold backup, backing up OUD_INSTANCE_HOME is sufficient.

Oracle Internet Directory

Oracle Internet Directory instance

Oracle Internet Directory data in database

File Copy

RMAN

See Oracle Fusion Middleware Administrator's Guide for more information.

Oracle Virtual Directory

Oracle Virtual Directory Instance

File Copy

See Oracle Fusion Middleware Administrator's Guide for more information.

Third Party LDAP

Binaries

LDAP data

  

See your vendor documentation.

Domain Home

ASERVER_HOME

MSERVER_HOME

File Copy

ASERVER_HOME is on shared storage, so only requires backup from one host.

MSERVER_HOME is on local storage. Back up each host individually.

Oracle HTTP Server

WEB_ORACLE_INSTANCE

File Copy

WEB_ORACLE_INSTANCE is on local storage. Back up each WEBHOST individually.

17.6.3 Performing Backups During Installation and Configuration

It is an Oracle best practices recommendation to create a backup after successfully completing the installation and configuration of each tier, or at another logical point. Create a backup after verifying that the installation so far is successful. This is a quick backup for the express purpose of immediate restoration in case of problems in later steps. The backup destination is the local disk. You can discard this backup when the enterprise deployment setup is complete. After the enterprise deployment setup is complete, you can initiate the regular deployment-specific Backup and Recovery process.

For more details, see the Oracle Fusion Middleware Administrator's Guide.

For information on database backups, refer to the Oracle Database Backup and Recovery User's Guide.

This section contains the following topics:

17.6.3.1 Backing Up Middleware Home

Back up the middleware home whenever you create a new one or add components to it.

17.6.3.2 Backing Up LDAP Directories

Whenever you perform an action which updates the data in LDAP, back up the directory contents.

This section contains the following topics:

17.6.3.2.1 Backing Up Oracle Unified Directory

To backup Oracle Unified Directory, perform the following steps:

  1. Shut down the Oracle Unified Directory Instances as described in Section 17.1, "Starting and Stopping Oracle Identity Management Components."

  2. Back up Oracle Unified Directory instance directories on each host.

  3. Restart the Oracle Unified Directory instances as described in Section 17.1, "Starting and Stopping Oracle Identity Management Components."

17.6.3.2.2 Backing up Oracle Internet Directory

To back up an Oracle Internet Directory instance:

  1. Shut down the instance using opmnctl located under the OID_ORACLE_INSTANCE/bin directory:

    OID_ORACLE_INSTANCE/bin/opmnctl stopall

  2. Back up the Database hosting the Oracle Internet Directory data and the Oracle Internet Directory instance home on each host.

  3. Start up the instance using opmnctl located under the OID_ORACLE_INSTANCE/bin directory:

    OID_ORACLE_INSTANCE/bin/opmnctl startall
17.6.3.2.3 Backing up Oracle Virtual Directory

To back up an Oracle Virtual Directory instance:

  1. Shut down the instance using opmnctl located under the OVD_ORACLE_INSTANCE/bin directory:

    OVD_ORACLE_INSTANCE/bin/opmnctl stopall

  2. Back up the Oracle Virtual Directory Instance home on each LDAP host.

  3. Start up the instance using opmnctl located under the OVD_ORACLE_INSTANCE/bin directory:

    OVD_ORACLE_INSTANCE/bin/opmnctl startall
17.6.3.2.4 Backing Up Third-Party Directories

Refer to your operating system vendor's documentation for information about backing up directories.

17.6.3.3 Backing Up the Database

Whenever you create add a component to the configuration, back up the IDMDB database. Perform this backup after creating domains or adding components such as Access Manager.

17.6.3.4 Backing Up the WebLogic Domain

To back up the WebLogic domain, perform these steps:

  1. Shut down the WebLogic administration server and any managed servers running in the domain as described in Section 17.1, "Starting and Stopping Oracle Identity Management Components."

  2. Back up the ASERVER_HOME directory from shared storage.

  3. Back up the MSERVER_HOME directory from each host.

17.6.3.5 Backing Up the Web Tier

To back up the web tier, perform these steps:

  1. Shut down the Oracle HTTP Server as described in Section 17.1, "Starting and Stopping Oracle Identity Management Components."

  2. Back up the WEB_ORACLE_INSTANCE.

  3. Start the Oracle HTTP Server as described in Section 17.1, "Starting and Stopping Oracle Identity Management Components."

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

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

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

17.7.3 Patching Oracle Unified Directory 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 or Oracle Virtual Directory server on the host you want to patch (IDMHOST1).

  3. Apply the patch.

  4. Restart the Oracle Unified Directory.

  5. Test the patch.

  6. Route the traffic to LDAPHOST1 again.

  7. Verify the applications are working properly.

  8. Route the LDAP traffic on IDMHOST2 to IDMHOST1.

  9. Repeat Steps 2-5 on IDMHOST2

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

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

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

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

    • IDMHOST2: 100.200.140.205

    • ADMINVHN: 100.200.140.206

      This is the Virtual IP address where the Administration Server is running, assigned to interface:index (for example, eth1:2), available in IDMHOST1 and 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.

Linux

  1. Stop the Administration Server as described in Section 17.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 eth0:1 down

    2. Run the following command on IDMHOST2:

      /sbin/ifconfig interface:index IP_Address netmask netmask

      For example:

      /sbin/ifconfig eth0:1 10.0.0.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 -q -U -c 3 -I eth0 10.0.0.1

17.9.2 Starting the Administration Server on IDMHOST2

Perform the following steps to start Node Manager on IDMHOST2.

  1. On IDMHOST1, unmount the Administration Server domain directory. For example:

    umount /u01/oracle

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

    mount /u01/oracle

  3. Start Node Manager by using the following commands:

    cd WL_HOME/server/bin
./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 17.1.5.3, "Starting Node Manager for an Administration Server."

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

    Note:

    Use the full path name for ASERVER_HOME in the WLST nmConnect command.

17.9.3 Validating Access to IDMHOST2 Through Oracle HTTP Server

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

    http://ADMINVHN.mycompany.com/console

    where 7001 is WLS_ADMIN_PORT in Section B.3.

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

    http://ADMINVHN.mycompany.com/em

If you are using a split domain topology, perform the same steps to check that you can Access the Administration Server when it is running on IDMHOST2.

17.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, unmount the Administration server domain directory. For example:

    umount /u01/oracle

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

    mount /u01/oracle

  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

    For example:

    /sbin/ifconfig eth0:1 down

  5. Run the following command on IDMHOST1:

    /sbin/ifconfig interface:index IP_Address netmask netmask

    For example:

    /sbin/ifconfig interface:index 100.200.140.206 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 running

    /sbin/arping -q -U -c 3 -I interface 100.200.140.206

    For example, run the following command from IDMHOST1:

    /sbin/arping -q -U -c 3 -I eth0 100.200.140.206

  7. If Node Manager is not already started on IDMHOST1, start it, as described in Section 17.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_Password, IDMHOST1,'5556','IDMDomain','ASERVER_HOME')
nmStart('AdminServer')

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

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

    where 7001 is WLS_ADMIN_PORT in Section B.3.

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

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

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

17.10.1 Troubleshooting Oracle Internet Directory

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

17.10.1.1 Oracle Internet Directory Server is Not Responsive.

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.

17.10.1.2 SSO/LDAP Application Connection Times Out

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.

17.10.1.3 LDAP Application Receives LDAP Error 53 (DSA Unwilling to Perform)

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

17.10.1.4 TNSNAMES.ORA, TAF Configuration, and Related Issues

Problem

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

Solution

See the Oracle Database High Availability Overview manual.

17.10.2 Troubleshooting Oracle Virtual Directory

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

17.10.2.1 Command Not Found Error When Running SSLServerConfig.sh

Problem

You get a command not found error when you run SSLServerConfig.sh, for example:

./SSLServerConfig.sh: line 169: 20110520125611: command not found

Solution

Edit the file orapki.sh (on Linux) and remove any blank lines at the end of the file. Save the file and run SSLServerConfig.sh again.

17.10.2.2 Oracle Virtual Directory is Not Responsive

Problem

Oracle Virtual Directory 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.

17.10.2.3 SSO/LDAP Application Connection Times Out

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.

17.10.2.4 TNSNAMES.ORA, TAF Configuration, and Related Issues

Problem

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

Solution

See the Oracle Database High Availability Overview manual.

17.10.2.5 SSLServerConfig.sh Fails with Error

Problem

When you run SSLServerConfig.sh for component OVD, sometime it fails with an error similar to this:

>>>Enter password for weblogic:
>>>Enter your keystore name [ovdks1.jks]:
Checking the existence of ovdks1.jks in the OVD...

>>>Failed to configure your SSL server wallet
>>>Please check /scratch/aime1/edgfa/idm//rootCA/keystores/ovd/ks_check.log for more information

In the log file, you see an error message like this:

Problem invoking WLST - Traceback (innermost last):
File "/scratch/aime1/edgfa/idm/rootCA/keystores/ovd/ovdssl-check.py", line 8, in ?
File "<iostream>", line 182, in cd
File "<iostream>", line 1848, in raiseWLSTExceptionWLSTException: Error occured while performing cd : Attributeoracle.as.ovd:type=component.listenersconfig.sslconfig,name=LDAP SSLEndpoint,instance=ovd1,component=ovd1 not found. Use ls(a) to view theattributes

Solution

The problem is intermittent. To work around the issue, re-run the script.

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

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

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

17.10.3.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, where Port 80 is HTTP_PORT and Port 443 is HTTP_SSL_PORT.

  2. Verify that WebGate is installed.

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

  4. When OBAccessClient.xml was first created, the file was not formatted. When the OHS is restarted, reexamine the file to ensure that it is now formatted. OHS 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.

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

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

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

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

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

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

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