This chapter describes how to configure Node Manager in accordance with Oracle best practice recommendations.
This chapter contains the following sections:
The security imposed by Java 7 means that the demo certificates need to be recreated with a higher level of encryption.
Note:
This procedure assumes you have applied WebLogic Server patch 13964737. For more information, see:"Mandatory Patches Required for Installing Oracle Identity Manager" in the Oracle Fusion Middleware Release Notes for Identity Management.
Once the patch has been installed using WebLogic smart update, the WebLogic demo certificates need to be created as follows:
Create a temporary working directory. For example:
mkdir /u01/lcm/tmp
Set JAVA_HOME to JAVA_HOME.
Add JAVA_HOME/bin to your system path. For example:
export PATH=$JAVA_HOME/bin:$PATH
Set up your WebLogic environment by executing the script setWLSEnv.sh. For example:
MW_HOME/wlserver10.3/server/bin/setWLSEnv.sh
Change directory to the temporary directory. For example:
cd /u01/lcm/tmp
Regenerate the certificates using the following commands:
java utils.CertGen -keyfilepass DemoIdentityPassPhrase -certfile democert -keyfile demokey -strength 2048
java utils.ImportPrivateKey -keystore DemoIdentity.jks -storepass DemoIdentityKeyStorePassPhrase -keyfile demokey.der -keyfilepass DemoIdentityPassPhrase -certfile democert.der -alias demoidentity
Shutdown all of the Node Managers, Managed Servers, and the Administration Server in the domain.
Back up the existing certificate. For example:
cp $MW_HOME/wlserver10.3/server/lib/DemoIdentity.jks $MW_HOME/wlserver_10.3/server/lib/DemoIdentity.orig
Move the certificate to the directory MW_HOME/wlserver10.3/server/lib. For example:
mv DemoIdentity.jks $MW_HOME/wlserver_10.3/server/lib
Remove your temporary working directory.
After you create WebLogic demo certificates, you must update the shell scripts to force the use of JSEE SSL. Now that you are using the new more secure JSEE certificate methods, the following Java arguments need to be added to various system shell scripts:
Edit the ASERVER_HOME/bin/startWeblogic.sh file to append -Dweblogic.ssl.JSSEEnabled=true to the line beginning with JAVA_OPTIONS="${SAVE_JAVA_OPTIONS}". For example:
JAVA_OPTIONS="${SAVE_JAVA_OPTIONS} -Dweblogic.ssl.JSSEEnabled=true"
Save the file.
Edit the MW_HOME/wlserver_10.3/common/bin/wlst.sh file to append -Dweblogic.security.SSL.enableJSSE=true -Dweblogic.ssl.JSSEEnabled=true to the line beginning with JVM_ARGS=. For example:
JVM_ARGS="-Dprod.props.file='${WL_HOME}'/.product.properties ${WLST_PROPERTIES} ${JVM_D64} ${MEM_ARGS} ${CONFIG_JVM_ARGS} -Dweblogic.security.SSL.enableJSSE=true -Dweblogic.ssl.JSSEEnabled=true"
Save the file.
Node Manager enables you to start and stop the Administration Server and the Managed Servers.
The procedures described in this chapter must be performed for various components of the enterprise deployment outlined in Section 2.3, "Understanding the Primary Oracle Identity and Access Management Topology Diagrams." Variables are used in this chapter to distinguish between component-specific items:
WLS_SERVER: This refers to a Managed WebLogic server for the enterprise deployment component (for example, WLS_OIM1).
HOST: This refers to a host machine for the enterprise deployment component (for example, OIMHOST1).
VIP: This refers to a virtual IP for the enterprise deployment component (for example, OIMHOST1VHN1).
The values to be used to these variables are provided in the component-specific chapters in this guide. Please note that the procedures in this chapter must be performed multiple times for each VIP-and-IP pair using the information provided in the component-specific chapters.
Oracle provides two main recommendations for Node Manager configuration in enterprise deployment topologies:
Oracle recommends placing the Node Manager configuration and log files in a location different from the default one (which is inside the Middleware Home where Node Manager resides). See Section 16.4, "Changing the Location of the Node Manager Log".
Oracle also recommends using host name verification for the communication between Node Manager and the servers in the domain. This requires the use of certificates for the different addresses used in the domain. This chapter explains the steps for configuring certificates in the hosts for host name verification. See Section 16.5, "Enabling Host Name Verification Certificates for Node Manager" for further details.
Note:
The passwords used in this guide are used only as examples. Use secure passwords in a production environment. For example, use passwords that consist of random sequences of both uppercase and lowercase characters as well as numbers.Move the Node Manager to a separate directory by doing the following:
Stop the Node Manager by killing the Node Manager process.
Move the configuration files to shared storage. While not mandatory, Oracle recommends removing the configuration files from the middleware home:
Create a directory for nodemanger using the following command:
mkdir -p SHARED_CONFIG_DIR/nodemanager/hostname.domain
Copy all of the files in the directory MW_HOME/wlserver_10.3/common/nodemanager to the directory SHARED_CONFIG_DIR/nodemanager/hostname.domain.
Edit the file SHARED_CONFIG_DIR/nodemanager/hostname.domain/nodemanager.properties update the directory paths in the entries DomainsFile and NodeManagerHome and LogFile to reference the directory SHARED_CONFIG_DIR/nodemanager/hostname.domain.
If this host contains an Administration Server, then in addition, set the following property in nodemanager.properties:
DomainRegistrationEnabled=true
Create a file called startNodeManagerWrapper.sh with the following contents:
#!/bin/sh # # This is a wrapper script that simply invokes "startNodeManager.sh" # script after setting the appropriate JAVA_OPTIONS environment # variable. # # Note: This script is provided as a convenience since we now have # host specific node manager home directories and we need to specify # the -DNodeManagerHome property prior to invoking "startNodeManager.sh" # script to start an instance of node manager process manually. # # $Header: faprov/modules/provisioning/framework/src/java/oracle/apps/fnd/provisioning/ant/taskdefs/util/startnodemanagerwrapper.template /main/3 2012/04/23 21:37:51 jjiembac Exp $ # WLS_HOME=IAD_MW_HOME/wlserver_10.3 NM_HOME=SHARED_CONFIG_DIR/nodemanager/hostname.domain # set an environment variable to allow node manager # to read it's host specific configuration JAVA_OPTIONS="-DNodeManagerHome=$NM_HOME -Dweblogic.security.SSL.enableJSSE=true $JAVA_OPTIONS" export JAVA_OPTIONS exec $WLS_HOME/server/bin/startNodeManager.sh
Save the file and give it execute permissions:
chmod 755 startNodeManagerWrapper.sh
Repeat this for each of the hosts OAMHOST1, OAMHOST2, OIMHOST1, OIMHOST2.
Restart Node Manager using the command startNodeManagerWrapper.sh.
If not already done, update the Node manager log location. Edit the Node Manager Properties file located at SHARED_CONFIG_DIR/nodemanager/hostname.domain/nodemanager.properties. Add the new location for the log file using the following line:
LogFile= SHARED_CONFIG_DIR/nodemanager/hostname.domain/nodemanager.log
Oracle best practice is to use a location outside the MW_HOME directory and inside the oracle base directory under which all oracle products are installed.
Restart Node Manager for the change to take effect.
This section describes how to set up host name verification certificates for communication between Node Manager and the Administration Server. It consists of the following steps:
Section 16.5.1, "Generating Self-Signed Certificates Using the utils.CertGen Utility"
Section 16.5.2, "Creating an Identity Keystore Using the utils.ImportPrivateKey Utility"
Section 16.5.3, "Creating a Trust Keystore Using the Keytool Utility"
Section 16.5.4, "Adding a Load Balancer Certificate to Trust Store"
Section 16.5.5, "Configuring Node Manager to Use the Custom Keystores"
Section 16.5.6, "Configuring the Managed WebLogic Servers to Use Custom Keystores"
Section 16.5.7, "Changing the Host Name Verification Setting for the Managed Servers"
The certificates added in this chapter (as an example) address a configuration where Node Manager listens on a physical host name (HOST.example.com) and a WebLogic Managed Server listens on a virtual host name (VIP.example.com). Whenever a server is using a virtual host name, it is implied that the server can be migrated from one node to another. Consequently, the directory where keystores and trust keystores are maintained ideally must reside on a shared storage that is accessible from the failover. If additional host names are used in the same or different nodes, the steps in this example must be extended to:
Add the required host names to the certificate stores (if they are different from HOST.example.com and VIP.example.com).
Change the identity and trust store location information for Node Manager (if the additional host names are used by Node Manager) or for the servers (if the additional host names are used by Managed Servers).
Follow these steps to create self-signed certificates on HOST. These certificates should be created using the network name or alias. The following examples configure certificates for HOST.example.com and VIP.example.com; that is, it is assumed that both a physical host name (HOST) and a virtual host name (VIP) are used in HOST. It is also assumed that HOST.example.com is the address used by Node Manager and VIP.example.com is the address used by a Managed Server or the Administration Server. This is the common situation for nodes hosting an Administration Server and a Fusion Middleware component, or for nodes where two Managed Servers coexist with one server listening on the physical host name and one server using a virtual host name (which is the case for servers that use migration servers). You must perform the following steps for each Managed Servers hostname and each Managed Servers virtual name (if it has one).
Set up your environment by running the WL_HOME/server/bin/setWLSEnv.sh script. In the Bourne shell, run the following commands:
cd WL_HOME/server/bin
. ./setWLSEnv.sh
Verify that the CLASSPATH environment variable is set:
echo $CLASSPATH
The directory created in Section 15.4.13, "Adding a Load Balancer Certificate to JDK Trust Stores" will be used for storing the certificates. Change directory to the keystores directory that was created using the following command:
cd SHARED_CONFIG_DIR/keystores
Run the utils.CertGen tool from the user-defined directory to create the certificates for both HOST.example.com and VIP.example.com.
Syntax (all on a single line):
java utils.CertGen Key_Passphrase Cert_File_Name Key_File_Name [export | domestic] [Host_Name]
Examples:
java utils.CertGen Key_Passphrase OIMHOST1.example.com_cert OIMHOST1.example.com_key domestic OIMHOST1.example.com java utils.CertGen Key_Passphrase OIMHOST1VHN1.example.com_cert OIMHOST1VHN1.example.com_key domestic OIMHOST1VHN1.example.com
Follow these steps to create an identity keystore on HOST:
Create a new identity keystore called appIdentityKeyStore using the utils.ImportPrivateKey utility. Create this keystore under the same directory as the certificates (that is, SHARED_CONFIG_DIR/keystores).
Note:
The Identity Store is created (if none exists) when you import a certificate and the corresponding key into the Identity Store using theutils.ImportPrivateKey utility.On HOST, import the certificate and private key for both HOST.example.com and VIP.example.com created above, into the Identity Store. Ensure that you use a different alias for each of the certificate/key pairs imported. Syntax (all on a single line):
java utils.ImportPrivateKey Keystore_File Keystore_Password Certificate_Alias_to_Use Private_Key_Passphrase Certificate_File Private_Key_File [Keystore_Type]]
Examples:
java utils.ImportPrivateKey appIdentityKeyStore.jks Key_Passphrase appIdentity-OIMHOST1.example.com Key_Passphrase SHARED_CONFIG_DIR/keystores/OIMHOST1.example.com_cert.pem SHARED_CONFIG_DIR/keystores/OIMHOST1.example.com_key.pem java utils.ImportPrivateKey appIdentityKeyStore.jks Key_Passphrase appIdentity-OIMHOST1VHN1.example.com Key_Passphrase SHARED_CONFIG_DIR/keystores/OIMHOST1VHN1.example.com_cert.pem SHARED_CONFIG_DIR/keystores/OIMHOST1VHN1.example.com_key.pem java utils.ImportPrivateKey appIdentityKeyStore.jks Key_Passphrase appIdentity-IGDADMINVHN.example.com Key_Passphrase SHARED_CONFIG_DIR/keystores/igdadminvhn.example.com_cert.pem SHARED_CONFIG_DIR/keystores/igdadminvhn.example.com_key.pem
Follow these steps to create the trust keystore on each host:
Copy the standard Java keystore to create the new trust keystore since it already contains most of the root CA certificates needed. Oracle does not recommend modifying the standard Java trust keystore directly. Copy the standard Java keystore CA certificates located under the WL_HOME/server/lib directory to the same directory as the certificates. For example:
cp WL_HOME/server/lib/cacerts SHARED_CONFIG_DIR/keystores/appTrustKeyStore.jks
The default password for the standard Java keystore is changeit. Oracle recommends always changing the default password. Use the keytool utility to do this. The syntax is:
keytool -storepasswd -new New_Password -keystore Trust_Keystore -storepass Original_Password
For example:
keytool -storepasswd -new Key_Passphrase -keystore appTrustKeyStore.jks -storepass changeit
The CA certificate CertGenCA.der is used to sign all certificates generated by the utils.CertGen tool. It is located in the WL_HOME/server/lib directory. This CA certificate must be imported into the appTrustKeyStore using the keytool utility. The syntax is:
keytool -import -v -noprompt -trustcacerts -alias Alias_Name -file CA_File_Location -keystore Keystore_Location -storepass Keystore_Password
For example:
keytool -import -v -noprompt -trustcacerts -alias clientCACert -file WL_HOME/server/lib/CertGenCA.der -keystore appTrustKeyStore.jks -storepass Key_Passphrase
Add the Load balancer certificate you obtained in Section 15.4.13, "Adding a Load Balancer Certificate to JDK Trust Stores", into the Node Manager Trust Store.
Load the certificate into the Node Manager Trust Store by running the following commands to import the CA certificate file, SHARED_CONFIG_DIR/keystores/login.example.com.pem, into the Node Manager trust store SHARED_CONFIG_DIR/keystores/appTrustKeyStore.jks:
set JAVA_HOME to IGD_MW_HOME/jdk set PATH to include JAVA_HOME/bin keytool -importcert -file SHARED_CONFIG_DIR/keystores/login.example.com.pem -trustcacerts -keystore SHARED_CONFIG_DIR/keystores/appTrustKeyStore.jks
To configure Node Manager to use the custom keystores, add the following lines to the end of the nodemanager.properties file located in the SHARED_CONFIG_DIR/nodemanager/hostname.domain directory:
KeyStores=CustomIdentityAndCustomTrust CustomIdentityKeyStoreFileName=Identity_Keystore CustomIdentityKeyStorePassPhrase=Identity_Keystore_Password CustomIdentityAlias=appIdentity-OIMHOST1.example.com CustomIdentityPrivateKeyPassPhrase=Private_Key_Used_When_Creating_Certificate
For example:
KeyStores=CustomIdentityAndCustomTrust CustomIdentityKeyStoreFileName=SHARED_CONFIG_DIR/keystores/appIdentityKeyStore.jks CustomIdentityKeyStorePassPhrase=Key_Passphrase CustomIdentityAlias=appIdentity-OIMHOST1.example.com CustomIdentityPrivateKeyPassPhrase=Key_Passphrase
The passphrase entries in the nodemanager.properties file get encrypted when you start Node Manager. For security reasons, minimize the time the entries in the nodemanager.properties file are left unencrypted. After you edit the file, start Node Manager as soon as possible so that the entries get encrypted.
Note:
Each Node manager must point to a different identity alias to send the correct certificate to the Administration Server. In case you are using the WL_HOME/server/bin directory to start Node Manager and have not configured separate nodemanager directories, as described in this document, then you must set different environment variables before starting Node Manager in the different nodes:cd WL_HOME/server/bin export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentity-OIMHOST1.example.com cd WL_HOME/server/bin export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentity-OIMHOST2.example.com
Make sure to specify the custom identity alias specifically assigned to each host, for example appIdentity1 for HOST1 and appIdentity2 for HOST2.
Follow these steps to configure the identity and trust keystores for each Managed Server:
Log in to Oracle WebLogic Server Administration Console at the URL listed in Section 31.2, "About Identity and Access Management Console URLs"
Click Lock and Edit.
Expand the Environment node in the Domain Structure window.
Click Servers.
The Summary of Servers page appears.
Click the name of the server for which you want to configure the identity and trust keystores. The settings page for the selected server is displayed.
Select Configuration, then Keystores.
Click Change next to the Keystores label. On the Change page, change the keystrokes to Custom Identity and Custom Trust, and click Save.
In the Identity section, define attributes for the identity keystore:
Custom Identity Keystore: The fully qualified path to the identity keystore:
SHARED_CONFIG_DIR/keystores/appIdentityKeyStore.jks
Custom Identity Keystore Type: Leave blank; it defaults to JKS.
Custom Identity Keystore Passphrase: The password (Keystore_Password) you provided in Section 16.5.3, "Creating a Trust Keystore Using the Keytool Utility" This attribute is optional or required depending on the type of keystore. All keystores require the passphrase to write to the keystore. However, some keystores do not require the passphrase to read from the keystore. WebLogic Server only reads from the keystore, so whether you define this property depends on the requirements of the keystore.
In the Trust section, define properties for the trust keystore:
Custom Trust Keystore: The fully qualified path to the trust keystore:
SHARED_CONFIG_DIR/keystores/appTrustKeyStore.jks
Custom Trust Keystore Type: Leave blank; it defaults to JKS.
Custom Trust Keystore Passphrase: The password you provided as New_Password in Section 16.5.3, "Creating a Trust Keystore Using the Keytool Utility" This attribute is optional or required depending on the type of keystore. All keystores require the passphrase to write to the keystore. However, some keystores do not require the passphrase to read from the keystore. WebLogic Server only reads from the keystore, so whether you define this property depends on the requirements of the keystore.
Click Save.
Click Activate Changes in the Administration Console's Change Center to make the changes take effect.
Select Configuration, then SSL.
Click Lock and Edit.
In the Private Key Alias field, enter the alias you used for the host name the Managed Server listens on, for example:
For wls_oim1, use appIdentity-OIMHOST1.example.com
For ADMINSERVER, use appIdentity-IGDADMINVHN.example.com
In the Private Key Passphrase and the Confirm Private Key Passphrase fields, enter the password for the keystore that you created in Section 16.5.2, "Creating an Identity Keystore Using the utils.ImportPrivateKey Utility"
Click Save.
Click Activate Changes in the Administration Console's Change Center to make the changes take effect.
Restart the server for which the changes have been applied, as described in Section 31.1, "Starting and Stopping Enterprise Deployment Components"
Once the previous steps have been performed, set host name verification for the affected Managed Servers to BEA Hostname Verifier. To do this, perform the following steps:
Log in to Oracle WebLogic Server Administration Console.
Select Lock and Edit from the change center.
Expand the Environment node in the Domain Structure window.
Click Servers.
The Summary of Servers page appears.
Select the Managed Server in the Names column of the table.
The settings page for the server appears.
Open the SSL tab.
Expand the Advanced section of the page.
Set host name verification to BEA Hostname Verifier.
Select Use JSEE SSL.
Note:
This value must be selected after applying the mandatory WebLogic patches.Click Save.
Click Activate Changes.