Oracle® Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management (Oracle Fusion Applications Edition) 11g Release 1 (11.1.4) Part Number E21032-11 |
|
|
PDF · Mobi · ePub |
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:
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:
Section 20.1.2, "Starting and Stopping Oracle Virtual Directory"
Section 20.1.3, "Starting and Stopping Oracle Internet Directory"
Section 20.1.4, "Starting, Stopping, and Restarting Oracle HTTP Server"
Section 20.1.6, "Starting, Stopping, and Restarting WebLogic Administration Server"
Section 20.1.7, "Starting, Stopping, and Restarting Oracle Identity Manager"
Section 20.1.8, "Starting, Stopping, and Restarting Oracle Access Manager Managed Servers"
When starting up your entire infrastructure, start the components in the following order, (ignoring those not in your topology):
Database(s)
Database Listener(s)
Oracle Internet Directory
Oracle Virtual Directory
Oracle Access Manager Server(s)
WebLogic Administration Server
Oracle HTTP Server(s)
SOA Server(s)
Oracle Identity Manager Server(s)
Start and stop Oracle Virtual Directory as follows.
Start system components such as Oracle Virtual Directory by typing:
ORACLE_INSTANCE/bin/opmnctl startall
You can verify that the system components have started by executing:
ORACLE_INSTANCE/bin/opmnctl status -l
Start and stop Oracle Internet Directory as follows.
Start system components such as Oracle Internet Directory by typing
ORACLE_INSTANCE/bin/opmnctl startall
You can verify that the system components have started by executing:
ORACLE_INSTANCE/bin/opmnctl status -l
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=/u01/app/oracle/admin/web[1-2]
export PATH=$ORACLE_HOME/opmn/bin:$PATH
Start the Oracle web tier by issuing the command:
opmnctl startall
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.
Start and stop the Node Manager as follows:
If the Node Manager being started is the one that controls the Administration Server, then prior to starting the Node Manager issue the command:
export JAVA_OPTIONS=-DDomainRegistrationEnabled=true
To start Node Manager, issue the commands:
cd ORACLE_BASE/product/fmw/wlserver_10.3/server/bin
./startNodeManager.sh
To stop Node Manager, kill the process started in the previous section.
cd ORACLE_BASE/product/fmw/wlserver_10.3/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.
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 ORACLE_BASE
/admin/
domain_name
/aserver/
domain_name
/config/nodemanager/nm_password.properties
file.
The recommended way to start the Administration server is to use WLST and connect to Node Manager:
cd ORACLE_BASE/product/fmw/oracle_common/common/bin
./wlst.sh
Once in WLST shell, execute
nmConnect('Admin_User','Admin_Password','ADMINHOST1','5556', 'domain_name','/u01/app/oracle/admin/domain_name/aserver/domain_name') nmStart('AdminServer')
For example:
nmConnect('weblogic','Admin_Password','OIMHOST1','5556', 'OIMDomain','/u01/app/oracle/admin/OIMDomain/aserver/OIMDomain')
Alternatively, you can start the Administration server by using the command:
DOMAIN_HOME/bin/startWeblogic.sh
To stop the Administration Server, log in to the WebLogic console using the URL listed in Section 20.2, "About Identity Management Console URLs."
Then proceed as follows:
Select Environment - Servers from the Domain Structure menu.
Click the Control tab.
Select AdminServer(admin).
Click Shutdown and select Force Shutdown now.
Click Yes when asked to confirm that you want to shut down the Administration Server.
Start and stop Oracle Identity Manager and Oracle SOA Suite servers as follows:
To start the Oracle Identity Manager Managed Server(s), log in to the WebLogic console using the URL listed in Section 20.2, "About Identity Management Console URLs."
Then proceed as follows:
Select Environment - Servers from the Domain Structure menu.
Click the Control tab.
Select SOA Servers (WLS_SOA1 and/or WLS_SOA2).
Note:
You can start the Oracle Identity Manager and Oracle SOA Suite servers independently of each other. There is no dependency in their start order. However, the SOA server must be up and running for all of the Oracle Identity Manager functionality to be available.
Click the Start button.
Click Yes when asked to confirm that you want to start the server(s).
After WLS_SOA1 and/or WLS_SOA2 have started, select WLS_OIM1 and/or WLS_OIM2
Click Start.
Click Yes when asked to confirm that you want to start the server(s).
To stop the Oracle Identity Manager Managed Server(s), log in to the WebLogic console using the URL listed in Section 20.2, "About Identity Management Console URLs." Then proceed as follows:
Select Environment - Servers from the Domain Structure menu.
Click the Control tab.
Select OIM Servers (WLS_OIM1 and/or WLS_OIM2) and (WLS_SOA1 and/or WLS_SOA2).
Click the Shutdown button and select Force Shutdown now.
Click Yes when asked to confirm that you want to shutdown the server(s).
Start and stop Oracle Access Manager Managed Servers as follows:
To start the Oracle Access Manager Managed Server(s), log in to the WebLogic console using the URL listed in Section 20.2, "About Identity Management Console URLs."
Then proceed as follows:
Select Environment - Servers from the Domain Structure menu.
Click the Control tab.
Select OAM Servers (WLS_OAM1 and/or WLS_OAM2).
Click the Start button.
Click Yes when asked to confirm that you want to start the server(s).
To stop the Oracle Access Manager Managed Server(s), log in to the WebLogic console using the URL listed in Section 20.2, "About Identity Management Console URLs." Then proceed as follows:
Select Environment - Servers from the Domain Structure menu.
Click the Control tab.
Select OAM Servers (WLS_OAM1 and/or WLS_OAM2).
Click the Shutdown button and select Force Shutdown now.
Click Yes when asked to confirm that you want to shut down the server(s).
Table 20-1 lsts the administration consoles used in this guide and their URLs.
Table 20-1 Console URLs
Domain | Console | URL |
---|---|---|
IDMDomain |
WebLogic Administration Console |
|
Enterprise Manager FMW Control |
|
|
OAM Console |
|
|
ODSM |
|
|
OIMDomain |
OIM Console |
|
WebLogic Administration Console |
|
|
Enterprise Manager FMW Control |
|
This section provides information about monitoring the Identity Management enterprise deployment described in this manual.
This section contains the following topics:
You can use the Oracle Enterprise Manager Fusion Middleware Control to monitor Oracle Internet Directory, as follows:
On the Farm home page for an Identity Management domain, view the Fusion Middleware pie chart. This chart shows the status of Oracle Fusion Middleware components. Green sections of the chart indicate components that are up and running properly, and red sections indicate components that are down.
The Identity and Access section below the chart includes the name of each individual Oracle Internet Directory instance (for example: oid1, oid2), its status, host name, and CPU usage percentage. A green arrow in the Status column indicates that the instance is up and running properly, and a red arrow indicates the instance is down. Click the name of an individual Oracle Internet Directory instance to view the home page for that instance.
The home page for an instance displays metrics for the instance such as performance, load, security, response, CPU utilization %, and memory utilization %.
When you perform an Oracle Internet Directory installation using Oracle Identity Management 11g Installer, the default component name that the installer assigns to the Oracle Internet Directory instance is oid1. You cannot change this component name.
The instance specific configuration entry for this Oracle Internet Directory instance is cn=oid1, cn=osdldapd, cn=subconfigsubentry
.
If you perform a second Oracle Internet Directory installation on another computer and that Oracle Internet Directory instance uses the same database as the first instance, the installer detects the previously installed Oracle Internet Directory instance on the other computer using the same Oracle database, so it gives the second Oracle Internet Directory instance a component name of oid2
.
The instance specific configuration entry for the second Oracle Internet Directory instance is cn=oid2, cn=osdldapd, cn=subconfigsubentry
. A change of properties in the entry cn=oid2, cn=osdldapd, cn=subconfigsubentry
does not affect the first instance (oid1
).
If a third Oracle Internet Directory installation is performed on another computer and that instance uses the same database as the first two instances, the installer gives the third Oracle Internet Directory instance a component name of oid3, and so on for additional instances on different hosts that use the same database.
Note that the shared configuration for all Oracle Internet Directory instances is cn=dsaconfig, cn=configsets,cn=oracle internet directory
. A change in this entry affects all the instances of Oracle Internet Directory.
This naming scheme helps alleviate confusion when you view your domain using Oracle Enterprise Manager by giving different component names to your Oracle Internet Directory instances.
You can use the Oracle Enterprise Manager Fusion Middleware Control to monitor Oracle Virtual Directory, as follows:
On the Farm home page for an Identity Management domain, view the Fusion Middleware pie chart. This chart shows the status of Oracle Fusion Middleware components. Green sections of the chart indicate components that are up and running properly, and red sections indicate components that are down.
The Identity and Access section below the chart includes the name of each instance of the Oracle Virtual Directory application (for example, ovd1, ovd2), its status, and host name. A green arrow in the Status column indicates that the Oracle Virtual Directory instance is up and running properly, and a red arrow indicates the instance is down. Click the name of an individual Oracle Virtual Directory instance to view the home page for that instance.
The home page for an instance displays metrics and configurations for the instance such as:
Oracle Virtual Directory status - A green arrow next to the Oracle Virtual Directory instance name at the top of the page indicates that the instance is up and running properly and a red arrow indicates that the instance is down.
Current Load - This indicates the current work load of this Oracle Virtual Directory instance. It includes three metrics: Open Connections, Distinct Connected Users, and Distinct Connected IP Addresses.
Average Response Time Metric - This displays the average time (in milliseconds) to complete an LDAP search request.
Operations Metric - This displays the average number of LDAP search requests finished per millisecond.
Listeners - This table lists the listeners configured for this Oracle Virtual Directory instance to provide services to clients.
Adapters - This table lists existing adapters configured with the Oracle Virtual Directory instance. Oracle Virtual Directory uses adapters to connect to different underlying data repositories.
Resource Usage - On the right hand side of the page, the CPU and memory utilization metrics are displayed to indicate the system resources consumed by the Oracle Virtual Directory instance.
You can use Oracle Enterprise Manager Fusion Middleware Control to monitor Managed Servers and other Fusion Middleware components, such as Oracle Access Manager, Oracle Identity Manager, and SOA. For more information, see the administrator guides listed in the Preface under "Related Documents".
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:
The Oracle Identity Management topology described in the guide has three tiers: the directory tier, application tier and web tier. The components in all the three tiers can be scaled up by adding a new server instance to a node that already has one or more server instances running.
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 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 20.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:
The directory tier consists of the two Oracle Internet Directory nodes (LDAPHOST1 and LDAPHOST2), each running an Oracle Internet Directory instance and the two Oracle Virtual Directory nodes (LDAPHOST1 and LDAPHOST2), each running an Oracle Virtual Directory instance. The Oracle Internet Directory or Oracle Virtual Directory instances can be scaled up on one or both the nodes.
The directory tier has two Oracle Internet Directory nodes (LDAPHOST1 and LDAPHOST2), each running an Oracle Internet Directory instance. The existing Oracle Identity Management binaries on either node can be used for creating the new Oracle Internet Directory instance.
To add a new Oracle Internet Directory instance to either Oracle Internet Directory node, follow the steps in Section 9.4.2, "Configuring an Additional Oracle Internet Directory Instance" with the following variations:
In step 2 and step 4, choose ports other than 389 and 636 since these ports are being used by the existing Oracle Internet Directory instance on the node.
Follow the steps in Section 9.5.1, "Registering Oracle Internet Directory with the WebLogic Server Domain (IDMDomain)" to register the new Oracle Internet Directory instance with the WebLogic domain. Use the location for the new Oracle Internet Directory instance as the value for ORACLE_INSTANCE.
Configure SSL server-authentication mode for the new instance as described in Section 9.5.3, "Configuring Oracle Internet Directory to Accept Server Authentication Mode SSL Connections."
Reconfigure the load balancer with the host and port information of the new Oracle Internet Directory instance.
Register the new Oracle HTTP Server instance as described in Section 9.5.1, "Registering Oracle Internet Directory with the WebLogic Server Domain (IDMDomain)."
The directory tier has two nodes (LDAPHOST1 and LDAPHOST2), each running an Oracle Virtual Directory instance. The existing Oracle Identity Management binaries on either node can be used for creating the new Oracle Virtual Directory instance.
To add a new Oracle Virtual Directory instance to either Oracle Virtual Directory node, follow the steps in Section 12.3.2, "Configuring an Additional Oracle Virtual Directory" with the following variations:
In step 2 and step 4, choose ports other than 6501 and 7501 since these ports are being used by the existing Oracle Virtual Directory instance on the node.
Follow the steps in these sections to register the new Oracle Virtual Directory instance with the WebLogic domain. Use the location for the new Oracle Virtual Directory instance as the value for ORACLE_INSTANCE
.
Reconfigure the load balancer with the host and port information of the new Oracle Virtual Directory instance.
The application tier consists of several nodes in pairs, depending on the products installed. These application servers run WebLogic Managed servers.
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 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 20.1, "Starting and Stopping Oracle Identity Management Components." Oracle recommends that you do this sequentially to prevent loss of service.
The application tier already has a node (IDMHOST2) running a Managed Server configured with Oracle Directory Services Manager components. The node contains a WebLogic Server home and an Oracle Fusion Middleware Identity Management Home on the local disk.
The existing installations (WebLogic Server home, Oracle Fusion Middleware home, and domain directories) can be used for creating a new Managed Server for the Oracle Directory Services Manager component.
Follow the steps in Section 10.4, "Expanding the ODSM Cluster."
Be sure to choose a port other than 7499, which is already in use.
Reconfigure the Oracle HTTP Server module with the new Managed Server. Follow the instructions in Chapter 7, "Configuring the Web Tier for an Enterprise Deployment" to complete this task.
Scale up Oracle Access Manager as follows:
Log in to the Oracle WebLogic Server Administration Console at the URL listed in Section 20.2, "About Identity Management Console URLs."
From the Domain Structure window of the Oracle WebLogic Server Administration Console, expand the Environment node and then Servers. The Summary of Servers page appears.
Click Lock & Edit from the Change Center menu.
Select an existing server on the host you want to extend, for example: WLS_OAM1
.
Click Clone.
Enter the following information:
Server Name: A new name for the server, for example: WLS_OAM3
.
Server Listen Address: The name of the host on which the Managed Server runs.
Server Listen Port: The port the new Managed Server uses. This port must be unique within the host.
Click OK.
Click the newly created server WLS_OAM3
Click Save.
Disable host name verification for the new Managed Server. Before starting and verifying the WLS_OAM3
Managed Server, you must disable host name verification. You can re-enable it after you have configured server certificates for the communication between the Oracle WebLogic Administration Server and the Node Manager in 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:
In Oracle Enterprise Manager Fusion Middleware Control, select Oracle WebLogic Server Administration Console.
Expand the Environment node in the Domain Structure window.
Click Servers. The Summary of Servers page appears.
Select WLS_OAM3 in the Names column of the table. The Settings page for server appears.
Click the SSL tab.
Click Advanced.
Set Hostname Verification to None
.
Click Save.
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:
Log in to the OAM console as the oamadmin
user. Use the URL listed in Section 20.2, "About Identity Management Console URLs."
Click the System Configuration tab.
Click Server Instances.
Select Create from the Actions menu.
Enter the following information:
Server Name: WLS_OAM3
Host: Host that the server 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.
Click Coherence tab.
Set Local Port to a unique value on the host.
Click Apply.
Restart the WebLogic Administration Server as described in Section 20.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 20.2, "About Identity Management Console URLs." Then proceed as follows:
Log in as the Oracle Access Manager Admin User you created inSection 11.5, "Preparing the Identity Store."
Click the System Configuration tab.
Expand Access Manager Settings - SSO Agents - OAM Agents.
Click the open folder icon, then click Search.
You should see the WebGate agent Webgate_IDM.
Click the agent Webgate_IDM.
Select Edit from the Actions menu.
Click +
in the Primary Server list (or the Secondary Server list if this is a secondary server).
Select the newly created managed server from the Server drop down list.
Set Max Connections to 4
.
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: 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> <Location /fusion_apps> 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>
<Location /fusion_apps>
SetHandler weblogic-handler
WebLogicCluster IDMHOST1.mycompany.com:14100,IDMHOST2.mycompany.com:14100,IDMHOST3.mycompany.com:14100
</Location>
Save the file and restart the Oracle HTTP server, as described in Section 20.1, "Starting and Stopping Oracle Identity Management Components."
You can now start the new Managed Server, as described in Section 20.1, "Starting and Stopping Oracle Identity Management Components."
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:
Log in to the Administration Console at the URL listed in Section 20.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:
Select Environment -> Servers from the Administration Console.
From the Change Center menu, click Lock and Edit.
Select the Managed Server that you want to clone (for example, WLS_OIM1 or WLS_SOA1).
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 OIMHOST1, which is already running WLS_SOA1 and WLS_OIM1.
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.
Create JMS Servers for SOA, Oracle Identity Manager, UMS, and BPM on the new Managed Server.
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.4.4, "Directory Structure."
Note:
This directory must exist before the Managed Server is started or the start operation fails.
ORACLE_BASE/admin/DOMAIN_NAME/cluster_name/jms/SOAJMSFileStore_N
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_SOA
n
).
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_SOA
n
.
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.4.4, "Directory Structure."
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.4.4, "Directory Structure."
ORACLE_BASE/admin/domain_name/cluster_name/jms/UMSJMSFileStore_N.
Note:
This directory must exist before the Managed Server is started or the start operation fails. You can also assign SOAJMSFileStore_
N
as store for the new UMS JMS servers. For the purpose of clarity and isolation, individual persistent stores are used in the following steps.
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_SOA
n
).
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.4.4, "Directory Structure."
ORACLE_BASE/admin/domain_name/cluster_name/jms/OIMJMSFileStore_N
Note:
This directory must exist before the Managed Server is started or the start operation fails. You can also assign SOAJMSFileStore_
N
as store for the new Oracle Identity Manager JMS Servers. For the purpose of clarity and isolation, individual persistent stores are used in the following steps.
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_OIM
n
).
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 SOAJMSServer
XXXXXX
resulting from the Configuration Wizard JMS configuration for the first two servers (WLS_SOA1
and WLS_SOA2
).
Click the SOAJMSServer
XXXXXX
subdeployment. Add the new JMS Server for SOA called SOAJMSServer_
N
to this subdeployment. Click Save
.
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 UCMJMSServer
XXXXXX
resulting from the Configuration Wizard JMS configuration for the first two servers (WLS_SOA1
and WLS_SOA2
).
Click the UMSJMSServer
XXXXXX
subdeployment. Add the new JMS Server for UMS called UMSJMSServer_
N
to this subdeployment. Click Save.
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 BPMJMSServer
XXXXXX
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.
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 OIMJMSServer
XXXXXX
resulting from the Configuration Wizard JMS configuration for the first two servers (WLS_OIM1
and WLS_OIM2
).
Click the OIMJMSServer
XXXXXX
subdeployment. Add the new JMS Server for Oracle Identity Manager called OIMJMSServer_
N
to this subdeployment. Click Save.
Configure Oracle Coherence, as described in Section 15.7, "Configuring Oracle Coherence for Deploying Composites."
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.
Disable host name verification for the new Managed Server. Before starting and verifying the WLS_SOA
n
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 OIMHOST
n
. 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:
In the Oracle Enterprise Manager Console, select Oracle WebLogic Server Administration Console.
Expand the Environment node in the Domain Structure window.
Click Servers. The Summary of Servers page appears.
Select WLS_SOAn
in the Names column of the table. The Settings page for the server appears.
Click the SSL tab.
Click Advanced.
Set Hostname Verification to None
.
Click Save.
Repeat Steps 6a through 6h to disable host name verification for the WLS_OIM
n
Managed Servers. In Step d, select WLS_OIMn
in the Names column of the table.
Click Activate Changes from the Change Center menu.
Update the SOA host and port using Oracle Enterprise Manager Fusion Middleware Control. Follow these steps:
Open a browser and go to Oracle Enterprise Manager Fusion Middleware Control at the URL listed in Section 20.2, "About Identity Management Console URLs."
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.
Navigate to Identity and Access, and then oim.
Right-click oim and navigate to System MBean Browser.
Under Application Defined MBeans, navigate to oracle.iam, Application:oim, XMLConfig, Config, XMLConfig.SOAConfig, and then SOAConfig.
Update the value for the Rmiurl attribute with the host and port of the new SOA server. Click Apply to save the changes.
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:
t3://soa_cluster
Restart the WebLogic Administration Server as described in Section 20.1, "Starting and Stopping Oracle Identity Management Components."
Start and test the new Managed Server from the Administration Console.
Shut down the existing Managed Servers in the cluster.
Ensure that the newly created Managed Server, WLS_SOA
n, is up.
Access the application on the newly created Managed Server (http://vip:port/soa-infra
). The application should be functional.
Configure the newly created managed server for server migration. Follow the steps in Section 17.7, "Configuring Server Migration Targets" to configure server migration.
Test server migration for this new server. Follow these steps from the node where you added the new server:
Stop the WLS_SOA
n 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
Watch the Node Manager Console. You should see a message indicating that the floating IP address for WLS_SOA1 has been disabled.
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.
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.
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 7, "Configuring the Web Tier for an Enterprise Deployment."
Use the Oracle Fusion Middleware 11g Web Tier Utilities Configuration Wizard to scale up the topology, as described in Chapter 7, "Configuring the Web Tier for an Enterprise Deployment."
Copy all files created in ORACLE_INSTANCE
/config/OHS/
component
/moduleconf
from the existing web tier configuration to the new one.
Register the new Oracle HTTP Server instance, as described in Section 8.8.4, "Registering Oracle HTTP Server with WebLogic Server."
Reconfigure the load balancer with the host and port information of the new Oracle HTTP Server instance.
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:
The directory tier consists of the two Oracle Internet Directory nodes (LDAPHOST1 and LDAPHOST2), each running an Oracle Internet Directory instance and the two Oracle Virtual Directory nodes (LDAPHOST1 and LDAPHOST2), each running an Oracle Virtual Directory instance. The Oracle Internet Directory or Oracle Virtual Directory instances can be scaled out by adding new nodes to the directory tier.
The directory tier has two Oracle Internet Directory nodes (LDAPHOST1 and LDAPHOST2), each running an Oracle Internet Directory instance. The Oracle Internet Directory instances can be scaled out by adding a new node to the existing Oracle Internet Directory cluster. To scale out Oracle Internet Directory instances, follow these steps:
Follow the steps in Section 9.4.2, "Configuring an Additional Oracle Internet Directory Instance" to add a new node running Oracle Internet Directory.
Follow the steps in Section 9.5.1, "Registering Oracle Internet Directory with the WebLogic Server Domain (IDMDomain)" to register the new Oracle Internet Directory instance with the WebLogic domain.
Configure SSL server authentication mode for the new instance, as described in Section 9.5.3, "Configuring Oracle Internet Directory to Accept Server Authentication Mode SSL Connections."
Reconfigure the load balancer with the host and port information of the new Oracle Internet Directory instance.
The directory tier has two nodes (LDAPHOST1 and LDAPHOST2), each running an Oracle Virtual Directory instance. Oracle Virtual Directory can be scaled out by adding a new node configured to run Oracle Virtual Directory to the directory tier. To scale out Oracle Virtual Directory instances, follow these steps:
Follow the steps in Section 12.3.2, "Configuring an Additional Oracle Virtual Directory" to add a new node running Oracle Virtual Directory.
Follow the steps in these sections to register the new Oracle Virtual Directory instance with the WebLogic domain.
Reconfigure the load balancer with the host and port information of the new Oracle Virtual Directory instance.
The application tier has two nodes (IDMHOST1 and IDMHOST2) running Managed Servers for Oracle Access Manager, and Oracle Directory Services Manager, and two nodes (OIMHOST1 and OIMHOST2) running the Oracle Identity Manager.
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 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 20.1, "Starting and Stopping Oracle Identity Management Components." Oracle recommends that you do this sequentially to prevent loss of service.
The application tier has two nodes (IDMHOST1 and IDMHOST2) running a Managed Server configured with Oracle Directory Services Manager. The Oracle Directory Services Manager instances can be scaled out by adding a new node with a Managed Server to the existing cluster.
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.
To scale out ODSM instances, follow these steps:
Follow the steps in Section 10.4, "Expanding the ODSM Cluster" to scale out Oracle Directory Services Manager instances in the topology.
Reconfigure the Oracle HTTP Server module with the new Managed Server.
Follow the steps in Section 10.6, "Configuring ODSM to work with the Oracle Web Tier"for the instructions to complete this task.
Add the newly added Managed Server host name and port to the list WebLogicCluster Parameter.
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.
On the new node, mount the existing Middleware home, which should include the SOA installation and the domain directory, and ensure that the new node has access to this directory, just like the rest of the nodes in the domain.
To update the Middleware home list, create (or edit, if another WebLogic installation exists in the node) the MW_HOME
/bea/beahomelist
file and add ORACLE_BASE
/product/fmw
to it.
Log in to the Oracle WebLogic Server Administration Console at the URL listed in Section 20.2, "About Identity Management Console URLs."
From the Domain Structure window of the Oracle WebLogic Server Administration Console, expand the Environment node and then Servers. The Summary of Servers page appears.
Click Lock & Edit from the Change Center menu.
Select an existing server on the host you want to extend, for example: WLS_OAM1.
Click Clone.
Enter the following information:
Server Name: A new name for the server, for example: WLS_OAM3
.
Server Listen Address: The name of the host on which the Managed Server runs.
Server Listen Port: The port the new Managed Server uses. This port must be unique within the host.
Click OK.
Click the newly created server WLS_OAM3.
Set the SSL listen port. This should be unique on the host that the Managed Server runs on.
Click Save.
Disable host name verification for the new Managed Server. Before starting and verifying the WLS_OAM3 Managed Server, you must disable host name verification. You can re-enable it after you have configured server certificates for the communication between the Oracle WebLogic Administration Server and the Node Manager in 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:
In Oracle Enterprise Manager Fusion Middleware Control, select Oracle WebLogic Server Administration Console.
Expand the Environment node in the Domain Structure pane.
Click Servers. The Summary of Servers page appears.
Select WLS_OAM3 in the Names column of the table. The Settings page for server appears.
Click the SSL tab.
Click Advanced.
Set Hostname Verification to None.
Click Save.
Click Activate Configuration from the Change Center menu.
Restart the WebLogic Administration Server as described in Section 20.1, "Starting and Stopping Oracle Identity Management Components."
Pack the domain on IDMHOST1 using the command:
pack.sh -domain=ORACLE_BASE/admin/IDMDomain/aserver/IDMDomain -template =/tmp/IDMDomain.jar -template_name="OAM Domain" -managed=true
The pack.sh
script is located in MW_HOME
/oracle_common/common/bin
.
Unpack the domain on the new host using the command:
unpack.sh -domain=ORACLE_BASE/admin/IDMDomain/mserver/IDMDomain -template=/tmp/IDMDomain.jar -app_dir=ORACLE_BASE/admin/IDMDomain/mserver/applications
The unpack.sh
script is located in MW_HOME
/oracle_common/common/bin
.
Start Node Manager and update the property file.
Start and stop Node Manager as described in Section 20.1, "Starting and Stopping Oracle Identity Management Components."
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
Start Node Manager once again as described in Section 20.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:
Log in to the OAM console as the oamadmin
user. Use the URL listed in Section 20.2, "About Identity Management Console URLs."
Click the System Configuration tab.
Click Server Instances.
Select Create from the Actions menu.
Enter the following information:
Server Name: WLS_OAM3
Host: Host that the server 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.
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 20.2, "About Identity Management Console URLs." Then proceed as follows:
1. Log in as the Oracle Access Manager admin user you created in Section 11.5, "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 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: 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> <Location /fusion_apps> 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> <Location /fusion_apps> SetHandler weblogic-handler WebLogicCluster IDMHOST1.mycompany.com:14100,IDMHOST2.mycompany.com:14100,IDMHOST3.mycompany.com:14100 </Location>
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 15.7, "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:
ORACLE_HOME
/oui/bin/attachHome.sh
To update the Middleware home list to add or remove a WL_HOME
, edit the user_home
/bea/beahomelist
file. See the following steps.
Follow these steps for scaling out the topology:
On the new node, mount the existing Middleware home, which should include the 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.
To attach IAM_HOME
in shared storage to the local Oracle Inventory, execute the following command:
cd ORACLE_BASE/product/fmw/iam/oui/bin /attachHome.sh -jreLoc JAVA_HOME
To update the Middleware home list, create (or edit, if another WebLogic installation exists in the node) the MW_HOME
/bea/beahomelist
file and add ORACLE_BASE
/product/fmw
to it.
Log in to the Oracle WebLogic Administration Console at the URL listed in Section 20.2, "About Identity Management Console URLs."
Create a new machine for the new node to be used, and add the machine to the domain.
Update the machine's Node Manager's address to map the IP address of the node that is being used for scale out.
Use the Oracle WebLogic Server Administration Console to clone the managed servers WLS_OIM
and WLS_SOA1
into new Managed Servers. Name them WLS_SOA
n
and WLS_OIM
n
, 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.
Assign the host names or IP addresses to the listen addresses of the new Managed Servers.
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.
Create JMS servers for SOA, Oracle Identity Manager (if applicable), and UMS on the new Managed Server.
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.4.4, "Directory Structure." For example:
ORACLE_BASE
/admin/domain_name/cluster_name/jms/SOAJMSFileStore_
N
Note:
This directory must exist before the Managed Server is started or the start operation fails.
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_SOA
n
).
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.4.4, "Directory Structure."
ORACLE_BASE
/admin/domain_name/cluster_name/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.
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_SOA
n
).
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.4.4, "Directory Structure."
ORACLE_BASE
/admin/domain_name/cluster_name/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.
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_SOA
n
).
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.4.4, "Directory Structure."
ORACLE_BASE/admin/domain_name/cluster_name/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.
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_OIM
n
).
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 BPMJMSServer
XXXXXX
resulting from the Configuration Wizard JMS configuration for the first two servers (WLS_SOA1 and WLS_SOA2).
Click the BPMJMSServer
XXXXXX
subdeployment. Add the new JMS Server for BPM called BPMJMSServer_
N
to this subdeployment. Click Save.
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 SOAJMSServer
XXXXXX
subdeployment. Add the new JMS Server for SOA called SOAJMSServer_
N
to this subdeployment. Click Save.
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 UMSJMSServer
XXXXXX
subdeployment. Add the new JMS Server for UMS called UMSJMSServer_
N
to this subdeployment. Click Save.
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 OIMJMSServer
XXXXXX
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.
Click Activate Configuration from the Change Center menu.
Run the pack
command to create a template pack. Run it on IDMHOST1 if you are using a single domain or on OIMHOST1 if you are using a split domain. Proceed as follows:
cd ORACLE_COMMON_HOME/common/bin ./pack.sh -managed=true -domain=/u01/app/oracle/admin/domain_name/aserver/domain_name -template=/u01/app/oracle/admin/templates/oim_domain.jar -template_name="OIM Domain"
Run the scp
command on IDMHOST1 or OIMHOST1 to copy the template file created to IDMHOSTN or OIMHOSTN. For example:
scp ORACLE_BASE/admin/templates/oim_domain.jar OIMHOSTN:ORACLE_BASE/admin/templates/oim_domain.jar
Run the unpack
command on IDMHOSTN or OIMHOSTN to unpack the template in the Managed Server domain directory as follows:
cd ORACLE_BASE/product/fmw/soa/common/bin ./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name -template=ORACLE_BASE/admin/templates/oim_domain.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications
Configure Oracle Coherence, as described in Section 15.7, "Configuring Oracle Coherence for Deploying Composites."
Update the SOA host and port using Oracle Enterprise Manager Fusion Middleware Control. Follow these steps:
Open a browser and go to Oracle Enterprise Manager Fusion Middleware Control at the URL listed in Section 20.2, "About Identity Management Console URLs."
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.
Navigate to Identity and Access, and then oim.
Right-click oim and navigate to System MBean Browser.
Under Application Defined MBeans, navigate to oracle.iam, Application:oim, XMLConfig, Config, XMLConfig.SOAConfig, and then SOAConfig.
Update the value for the Rmiurl attribute with the host and port of the new SOA server. Click Apply to save the changes.
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:
t3://soa_cluster
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.
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 OIMHOSTn. 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:
Expand the Environment node in the Domain Structure window.
In the Oracle Enterprise Manager Console, select Oracle WebLogic Server Administration Console.
Click Servers. The Summary of Servers page appears.
Select WLS_SOAn
in the Names column of the table.
The Settings page for server appears.
Click the SSL tab.
Click Advanced.
Set Hostname Verification to None
.
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.
Click Activate Configuration from the Change Center menu.
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
Start and test the new Managed Server from the Oracle WebLogic Server Administration Console:
Shut down all the existing Managed Servers in the cluster.
Ensure that the newly created Managed Servers, WLS_SOAn
and WLS_SOAn, are running.
Access the applications on the newly created Managed Servers (http://vip:port/soa-infra
and http://vip:port/oim
). The applications should be functional.
Configure server migration for the new Managed Server.
Note:
Since this new node is using an existing shared storage installation, the node is already using a Node Manager and 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:
Log in to the Administration Console.
In the left pane, expand Environment and select Servers.
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.
Click the Migration tab.
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.
Select the Automatic Server Migration Enabled option. This enables the Node Manager to start a failed server on the target node automatically.
Click Save.
Restart the Administration Server, Managed Servers, and Node Manager.
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.
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:
Follow the steps in Section 6.2, "Installing Oracle HTTP Server." Alternatively, on the new node, mount the existing Middleware home, if you are using shared storage.
Follow the steps in Chapter 7, "Configuring the Web Tier for an Enterprise Deployment."
Copy all files created in ORACLE_INSTANCE
/config/OHS/
component
/moduleconf
from the existing web tier configuration to the new one.
If you have enabled Single Sign-on in the topology, you must update the WebTier configuration for Single Sign-on as described in
Register the new Oracle HTTP Server instance as described in Section 8.8.4, "Registering Oracle HTTP Server with WebLogic Server."
Reconfigure the load balancer with the host and port information of the new Oracle HTTP Server instance.
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 20-1 is a high-level architectural diagram of the Oracle Fusion Middleware Audit Framework.
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.
Table 20-2 shows the static artifacts to back up in the 11g Oracle Identity Management enterprise deployment.
Table 20-2 Static Artifacts to Back Up in the Identity Management Enterprise Deployment
Type | Host | Location | Tier |
---|---|---|---|
Oracle Home (database) |
Oracle RAC database hosts: OIDDBHOST1 OIDDBHOST2 |
User Defined |
Directory Tier |
|
LDAPHOST1 LDAPHOST2 |
Middleware home,
Identity Management Oracle home,
|
Directory Tier |
|
LDAPHOST1 LDAPHOST2 |
Middleware home,
Identity Management Oracle home,
|
Directory Tier |
|
IDMHOST1 IDMHOST2 |
Middleware Oracle home,
(Identity Management Oracle home ODSM,
(Admin server Oracle home,
|
Application Tier |
|
WEBHOST1 WEBHOST2 |
Middleware Oracle home,
Web Oracle Home,
Web Oracle Home,
|
Web Tier |
Install Related Files |
Each host |
OraInventory:
Windows registry: ( |
Not applicable. |
Table 20-3 shows the run-time artifacts to back up in the 11g Oracle Identity Management enterprise deployment:
Table 20-3 Run-Time Artifacts to Back Up in the Identity Management Enterprise Deployments
Type | Host | Location | Tier |
---|---|---|---|
Domain Home |
IDMHOST1 IDMHOST2 |
|
Application Tier |
Application Artifacts (ear and war files) |
IDMHOST1 IDMHOST2 |
Look at all the deployments, including Oracle Directory Services Manager, through the WebLogic Server Administration Console to identity all the application artifacts. |
Application Tier |
OID Instance Home |
LDAPHOST1 LDAPHOST2 |
OID Instance Home on LDAPHOST1: ORACLE_BASE/admin/oid1
OID Instance Home on LDAPHOST2: ORACLE_BASE/admin/oid2 |
Directory Tier |
OVD Instance Home |
LDAPHOST1 LDAPHOST2 |
OVD Instance Home on LDAPHOST1:
OVD Instance Home on LDAPHOST2:
|
Directory Tier |
Oracle RAC Databases |
OIDDBHOST1 OIDDBHOST2 |
User defined |
Directory Tier |
OAM |
OAMHOST1 OAMHOST2 |
All the configurations are within the respective home directories described in this table. There are no instance homes. |
Application Tier |
For more information on backup and recovery of Oracle Fusion Middleware components, see Oracle Fusion Middleware Administrator's Guide.
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:
Section 20.7.1, "Patching an Oracle Fusion Middleware Source File"
Section 20.7.2, "Patching Identity and Access Management in a Single Domain Topology"
Section 20.7.3, "Patching Identity and Access Management in a Split Domain Topology"
For information on patching an Oracle Fusion Middleware source file, see the Oracle Fusion Middleware Administrator's Guide.
In a single domain topology, apply patches as follows:
IDMDomain MW_HOME
Common patches
Oracle Access Manager Patches
Oracle Identity Manager Patches
ODSM Patches
IDM Tool Patches
In a split domain topology where Oracle Identity Manager is located in a domain separate from other components, apply patches as follows:
IDMDomain MW_HOME
Common patches
Oracle Access Manager Patches
ODSM Patches
IDM Tool Patches
OIMDomain MW_HOME
Common patches
Oracle Identity Manager Patches
IDM Tool Patches
Identity Management MW_HOME
Common patches
Oracle Internet Directory Patches
Oracle Virtual Directory Patches
It is not necessary to stop processes in the IDMDomain while applying patches to the OIMDomain. Similarly, it is not necessary to stop processes in the OIMDomain while applying patches to the IDMDomain.
To patch Oracle Identity Management components with minimal down time, it is recommended that you follow these guidelines:
Route the LDAP traffic from LDAPHOST1 to LDAPHOST2.
Bring down the Oracle Internet Directory or Oracle Virtual Directory server on the host on which you are applying the patch (LDAPHOST1).
Apply the Oracle Internet Directory patch or Oracle Virtual Directory patch on the host.
Start the Oracle Internet Directory or Oracle Virtual Directory server on the host.
Test the patch.
Route the traffic to LDAPHOST1 again.
Verify the applications are working properly.
Route the LDAP traffic on LDAPHOST2 to LDAPHOST1.
Bring down the Oracle Internet Directory or Oracle Virtual Directory server on the host on which you are applying the patch (LDAPHOST2).
Apply the Oracle Internet Directory patch or Oracle Virtual Directory patch on the host.
Start the Oracle Internet Directory or Oracle Virtual Directory server on the host.
Test the patch.
Route the traffic to both hosts on which the patch has been applied (LDAPHOST1 and LDAPHOST2).
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.
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:
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:
Section 20.9.1.1, "Oracle Internet Directory Server is Not Responsive."
Section 20.9.1.2, "SSO/LDAP Application Connection Times Out"
Section 20.9.1.3, "LDAP Application Receives LDAP Error 53 (DSA Unwilling to Perform)"
Section 20.9.1.4, "TNSNAMES.ORA, TAF Configuration, and Related Issues"
Problem
The Oracle Internet Directory server is not responsive. When the load balancing router is configured to send an ICMP message to the LDAP SSL port for monitoring, the Oracle Internet Directory server starting SSL negotiation sometimes hangs, and thus it is required that the load balancing router not use ICMP messages for monitoring the LDAP SSL port.
Solution
Use an alternative such as TCP or the LDAP protocol itself.
Also, monitoring the LDAP non-SSL port is sufficient to detect LDAP availability.
Problem
The SSO/LDAP Application connection is lost to Oracle Internet Directory server
Solution
Verify the load balancing router timeout and SSO/Application timeout configuration parameter. The SSO/LDAP application timeout value should be less than LBR IDLE time out.
Problem
The LDAP application is receiving LDAP Error 53 (DSA Unwilling to Perform). When one of the database nodes goes down during the middle of the LDAP transaction, the Oracle Internet Directory server sends error 53 to the LDAP client
Solution
To see why the Oracle Internet Directory database node went down, see the Oracle Internet Directory logs in this location:
ORACLE_INSTANCE/diagnostics/logs/OID/oidldapd01s*.log
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:
Section 20.9.2.1, "Command Not Found Error When Running SSLServerConfig.sh"
Section 20.9.2.2, "Oracle Virtual Directory is Not Responsive"
Section 20.9.2.3, "SSO/LDAP Application Connection Times Out"
Section 20.9.2.4, "TNSNAMES.ORA, TAF Configuration, and Related Issues"
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.bat
(on Windows) or orapki.sh
(on Linux) and remove any blank lines at the end of the file. Save the file and run SSLServerConfig.sh
again.
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.
Problem
The SSO/LDAP Application connection is lost to the Oracle Virtual Directory server.
Solution
Verify the load balancing router timeout and SSO/Application timeout configuration parameter. The SSO/LDAP application timeout value should be less than LBR IDLE time out.
Problem
Issues involving TNSNAMES.ORA, TAF configuration, and related issues.
Solution
See the Oracle Database High Availability Overview manual.
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.
This section describes some common problems that can arise with Oracle Directory Services Manager and the actions you can take to resolve the problem. It contains the following topics:
Section 20.9.3.2, "ODSM Does not Open When Invoked from Fusion Middleware Control"
Section 20.9.3.4, "ODSM Loses Connection and Displays Message that LDAP Server is Down"
Section 20.9.3.5, "ODSM Loses Connection to Instance Using ORAC Database"
After you have logged into Oracle Directory Services Manager, you can connect to multiple directory instances from the same browser window.
Avoid using multiple windows of the same browser program to connect to different directories at the same time. Doing so can cause a Target unreachable error.
You can log in to the same Oracle Directory Services Manager instance from different browser programs, such as Internet Explorer and Firefox, and connect each to a different directory instance.
If you change the browser language setting, you must update the session to use the new setting. To update the session, either disconnect the current server connection, refresh the browser page (either reenter the Oracle Directory Services Manager URL in the URL filed and press enter or press F5) and reconnect to the same server, or quit and restart the browser.
Problem
Oracle Directory Services Manager does not open after you attempt to invoke it from Oracle Enterprise Manager Fusion Middleware Control by selecting one of the options from the Directory Services Manager entry in the Oracle Virtual Directory menu in the Oracle Virtual Directory target or the Oracle Internet Directory menu in the Oracle Internet Directory target.
Solution
This is probably an installation problem. See the Oracle Fusion Middleware Installation Guide for Oracle Identity Management.
Problem
When you perform an Oracle Directory Services Manager failover using Oracle HTTP Server, the failover is not transparent. You see this behavior when you perform the following steps:
Oracle Directory Services Manager is deployed in a High Availability active-active configuration using Oracle HTTP Server.
Display an Oracle Directory Services Manager page using the Oracle HTTP Server name and port number.
Make a connection to an Oracle Internet Directory or Oracle Virtual Directory server.
Work with the Oracle Internet Directory or Oracle Virtual Directory server using the current Oracle Directory Services Manager Oracle HTTP Server host and port.
Shut down one Managed Server at a time using the WebLogic Server Administration Console.
Go back to the Oracle Directory Services Manager page and port, and the connection which was established earlier with Oracle Internet Directory or Oracle Virtual Directory. When you do, a message is displayed advising you to re-establish a new connection to the Oracle Directory Services Manager page.
Solution
If you encounter this problem, perform the following steps:
In your web browser, exit the current Oracle Directory Services Manager page.
Launch a new web browser page and specify the same Oracle Directory Services Manager Oracle HTTP Server name and port.
Re-establish a new connection to the Oracle Internet Directory or Oracle Virtual Directory server you were working with earlier.
Problem
Oracle Directory Services Manager temporarily loses its connection to Oracle Internet Directory and displays the message LDAP Server is down.
Solution
In a High Availability configuration where Oracle Directory Services Manager is connected to Oracle Internet Directory through a load balancer, Oracle Directory Services Manager reports that the server is down during failover from one instance of Oracle Internet Directory to another. In other configurations, this message might indicate that Oracle Internet Directory has been shut down and restarted. In either case, the connection is reestablished in less than a minute, and you are able to continue without logging in again.
Problem
Oracle Directory Services Manager temporarily loses its connection to an Oracle Internet Directory or Oracle Virtual Directory instance that is using an Oracle RAC Database. Oracle Directory Services Manager might display the message LDAP error code 53 - Function not implemented
.
Solution
This error can occur during failover of the Oracle Database that the Oracle Internet Directory or Oracle Virtual Directory instance is using. The connection is reestablished in less than a minute, and you are able to continue without logging in again.
Problem
You must perform the following steps to configure Oracle HTTP Server to route Oracle Directory Services Manager requests to multiple Oracle WebLogic Servers in a clustered Oracle WebLogic Server environment.
Solution
Perform these steps:
Create a backup copy of the Oracle HTTP Server's admin.conf
file, which is located in ORACLE_INSTANCE
/config
. The backup copy provides a source to revert to if you encounter problems after performing this procedure.
Add the following text to the end of the Oracle HTTP Server's admin.conf
file and replace the variable placeholder values with the host names and Managed Server port numbers specific to your environment. Be sure to use the <Location /odsm/ >
as the first line in the entry. Using <Location /odsm/faces >
or <Location /odsm/faces/odsm.jspx >
can distort the appearance of the Oracle Directory Services Manager interface.
<Location /odsm/ >
SetHandler weblogic-handler
WebLogicCluster host-name-1:managed-server-port,host-name_2:managed_server_port
</Location>
Restart the Oracle HTTP Server, as described in Section 20.1, "Starting and Stopping Oracle Identity Management Components," to activate the configuration change.
Note:
Oracle Directory Services Manager loses its connection and displays a session time-out message if the Oracle WebLogic Server in the cluster that it is connected to fails. Oracle Directory Services Manager requests is routed to the secondary Oracle WebLogic Server in the cluster that you identified in the httpd.conf file after you log back in to Oracle Directory Services Manager.
Problem
Attempting to access Oracle Directory Services Manager using a web browser fails.
Solution
Verify the Oracle Virtual Directory server is running. The Oracle Virtual Directory server must be running to connect to it from Oracle Directory Services Manager.
Verify you entered the correct credentials in the Server, Port, User Name and Password fields. You can execute an ldapbind command against the target Oracle Virtual Directory server to verify the server, user name, and password credentials.
Verify you are using a supported browser. Oracle Directory Services Manager supports the following browsers:
Internet Explorer 7
Firefox 2.0.0.2 and 3.0
Safari 3.1.2 (desktop)
Google Chrome 0.2.149.30
Note:
While Oracle Directory Services Manager supports all of the preceding browsers, only Internet Explorer 7 and Firefox 2.0.0.2 are certified.
This section describes some common problems that can arise with Oracle Access Manager and the actions you can take to resolve the problem. It contains the following topics:
Section 20.9.4.1, "User Reaches the Maximum Allowed Number of Sessions"
Section 20.9.4.2, "Policies Do Not Get Created When Oracle Access Manager is First Installed"
Section 20.9.4.3, "You Are Not Prompted for Credentials After Accessing a Protected Resource"
Section 20.9.4.5, "Unable to Create Keystore – Unable to Load Key"
Section 20.9.4.6, "Error When Starting OAM Managed Servers on Windows"
Problem
The Oracle Access Manager 11g 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:
Go to System Configuration -> Common Settings -> Session
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.
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.
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:
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.
Verify that WebGate is installed.
Verify that OBAccessClient.xml
was copied from ASERVER_HOME
/output
to the WebGate Lib directory and that OHS was restarted.
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.
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.
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.
Problem
You are trying to set up the keystore, as described in Section 14.11.3, "Setting up Keystore with the SSL Certificate and Private Key file of the Access Client." When you try to run the create keystore command:
openssl pkcs8 -topk8 -nocrypt -in ASERVER_HOME/output/Webgate_IDM/aaa_key.pem -inform PEM -out aaa_key.der -outform DER
you receive the error:
Unable to load key.
Solution
You have a password mismatch. To correct this, go to the OAM console, reset the WebGate Access Client password and try again.
Problem
On Windows, when you start the OAM managed servers, you see an error similar to this:
Caused by: java.net.SocketException: Address family not supported by protocolfamily: bind
Solution
Edit setDomainEnv.cmd
, which is located in MSERVER_HOME
/bin
and add the following parameters to the environment variable EXTRA_JAVA_PROPERTIES
:
-DuseIPv6Address=false -Djava.net.preferIPv6Addresses=false
Restart the Administration Server and all Managed Servers that are running.
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:
Section 20.9.5.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:
Delete the file /tmp/oaconfigplan.xml
.
Start the configuration again (OH/bin/config.sh
).
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.