IGL 7.2.1 Installation Guide

RSA Identity Governance and Lifecycle
Installation Guide
7.2.1
Contact Information
RSA Link at https://community.rsa.com contains a knowledgebase that answers common questions and
provides solutions to known problems, product documentation, community discussions, and case management.
Trademarks
RSA, RSA Security, the RSA Logo, and other trademarks, are trademarks of RSA Security LLC or its affiliates.
Other trademarks may be trademarks of their respective owners. For a list of RSA trademarks, go to
https://www.rsa.com/en-us/company/rsa-trademarks.
License agreement
This software and the associated documentation are proprietary and confidential to RSA Security LLC or its
subsidiaries, are furnished under license, and may be used and copied only in accordance with the terms of
such license and with the inclusion of the copyright notice below. This software and the documentation, and any
copies thereof, may not be provided or otherwise made available to any other person.
No title to or ownership of the software or documentation or any intellectual property rights thereto is hereby
transferred. Any unauthorized use or reproduction of this software and the documentation may be subject to
civil and/or criminal liability.
This software is subject to change without notice and should not be construed as a commitment by RSA
Security.
Third-party licenses
This product may include software developed by parties other than RSA. The text of the license agreements
applicable to third-party software in this product may be viewed by launching the RSA Identity Governance and
Lifecycle product and selecting the About menu. By using this product, a user of this product agrees to be fully
bound by terms of the license agreements.
Note on encryption technologies

This product may contain encryption technology. Many countries prohibit or restrict the use, import, or export
of encryption technologies, and current use, import, and export regulations should be followed when using,
importing or exporting this product.
Distribution
Use, copying, and distribution of any RSA Security software described in this publication requires an applicable
software license.
RSA Security LLC believes the information in this publication is accurate as of its publication date. The
information is subject to change without notice.
THE INFORMATION IN THIS PUBLICATION IS PROVIDED "AS IS." RSA SECURITY LLC MAKES NO
REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS
PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Copyright © 2020 RSA Security LLC or its affiliates. All Rights Reserved.

September 2020
RSA Identity Governance and Lifecycle Installation Guide 7.2.1
Contents
Preface 12
About This Guide 12
Documentation Set 12
Support and Service 12
Chapter 1: Installation Scenarios 13
Application Server Cluster Support for RSA Appliance and Software Bundle 13
Chapter 2: Installation Prerequisites 15
Supported Environments and Components 15
Port Requirements 15
Remote Agent Requirements 15
Verify Prerequisites for a Customer-Supplied Database 16
Plan the Customer-Supplied Database Configuration 16
Verify Prerequisites for an RSA Appliance 17
RSA Appliance Components 17
Supplied Hardware Components 17
Supplied Software Components 17
Additional Required Hardware Components 18
Font Requirement 18
Software Bundle Requirements 18
Hardware Requirements for the Software Bundle 18
Operating System Requirements for the Software Bundle 19
Required Packages 19
Customer-Supplied Database Requirements for the Software Bundle 20
Time Server Requirement for the Software Bundle 20
Font Requirement 20
Virtual Application Requirements 20
Database Requirements for the Virtual Application 21
Time Server Requirement for the Virtual Application 21
Font Requirement 21
Verify Prerequisites for WebSphere 21
Customer-Supplied Database Configuration for WebSphere Installations 22
3
WebSphere Application Server Requirements 22
Font Requirement 23
Verify Prerequisites for WebLogic 23
Customer-Supplied Database Configuration for WebLogic Installations 23
WebLogic Application Server Requirements 24
Font Requirement 24
Chapter 3: RSA Appliance Installation 25
Install the Appliance 25
Configure Appliance Network Settings 25
Log on to RSA Identity Governance and Lifecycle 27
Apply the Latest Operating System and Database Patch Updates to an Appliance 28
Confirm the Setting for the Encryption Key Directory 28
Using Non-restrictive Mode for the Encryption Key Directory 30
Error Messages 31
Implement Security Best Practices 32
Using a Signed Certificate for HTTPS Access to RSA Identity Governance and Lifecycle 32
Step 1: Generate a Key Pair 32
Step 2: Generate a Certificate Signing Request 33
Step 3: Import a Trusted Certificate 34
Step 4: Import a Signed Server Certificate into the RSA Identity Governance and Lifecycle Keystore35
Check Security Settings for RSA Identity Governance and Lifecycle 36
Setting Up User Access to RSA Identity Governance and Lifecycle 36
Chapter 4: Software Bundle Installation 37
Download the RSA Identity Governance and Lifecycle Installation Files 37
Before You Begin 37
Copy the Installation Files to the Installation Host 38
Perform the Installation 39
Perform the Installation as the Root User 40
Perform Installation as the Oracle User 42
Open Ports On the Firewall 43
Apply the Latest Database Patch Updates to a Software Bundle 43
4
Error Messages 46
Configure Datasources 47
Chapter 5: Virtual Application Installation 53
Download and Install the RSA Identity Governance and Lifecycle Virtual Application OVA 53
Set Up the Database for the Virtual Application 54
Set Up the RSA Identity Governance and Lifecycle Virtual Application 54
Manually Start the Virtual Application Setup Interface 57
Configure the Virtual Application Setup Interface to Run Automatically 57
Apply the Latest Operating System and Database Patch Updates to a Virtual Application 58
Error Messages 60
Configure Datasources 61
Chapter 6: WebSphere Installation 69
Before You Begin 69
5
If You Need a Modified Version of RSA Identity Governance and Lifecycle 69
Clustered Application Server and Oracle RAC Implementation Environments 70
Download Installation Files for WebSphere 72
Configure RSA Identity Governance and Lifecycle Resources on WebSphere 72
Configure Application Server Memory 72
Configure JVM Settings 73
Create Authentication Users 74
Create the ACM Oracle JDBC Provider 75
Create the JDBC Data Sources 76
Configure the WebSphere Bus and Bus Destinations 78
Configure a JMS Provider 79
Install RSA Identity Governance and Lifecycle Using the Aveksa EAR File 81
Install the Workflow Architect EAR File 82
Configure the RSA Identity Governance and Lifecycle Shared Library 83
Error Messages 86
Configure SSL for Internal Communication Between RSA Identity Governance and Lifecycle Components 87
Before You Begin 87
Download the server.keystore File 88
Create a Keystore in the WebSphere Server 88
Configure SSL in WebSphere 88
Configure the SSL Port 89
Configure SSL for External Communications (Browser or Web Services to RSA Identity Governance and
Lifecycle) 89
Create a Keystore on the WebSphere Server 90
Configure SSL in WebSphere 90
Configure JAAS Authentication in WebSphere 91
Enable Secure Cookies on WebSphere 92
Chapter 7: WebLogic Installation 95
6
Before You Begin 95
If You Need a Modified Version of RSA Identity Governance and Lifecycle 95
Clustered Application Server and Oracle RAC Implementation Environments 96
Download the Installation Files for WebLogic 98
Configure WebLogic JVM Settings for RSA Identity Governance and Lifecycle 99
Configure JVM Settings 99
Configure Application Server Memory 100
Edit the WebLogic Domain Environment Startup Script 100
Set JVM Arguments in the Admin Console 101
Configure JTA Timeout Setting 101
Configure RSA Identity Governance and Lifecycle Resources 101
Create Security Realm Users and Groups 101
Create the JDBC Data Sources 103
Java Messaging Service Configuration 105
Install RSA Identity Governance and Lifecycle Using the Aveksa EAR File 106
Install the Workflow Architect EAR File 107
Error Messages 110
Configure SSL for Internal Communication Between RSA Identity Governance and Lifecycle
Components 111
Before You Begin 112
Download the server.keystore File 112
Import the RSA Identity Governance and Lifecycle Certificates into the WebLogic Keystores 112
To import the private key into the identity keystore 113
To import the trusted certificate into the trusted keystore 113
To import the private key and the trusted certificate into the same keystore 113
Configure SSL for External Communications (Browser or Web Services to RSA Identity Governance
and Lifecycle) 114
Configure JAAS Authentication in WebLogic 115
Check Recommended Security Settings 116
Enable Secure Cookies on WebLogic 117
7
Chapter 8: Access Fulfillment Express (AFX) Installation 119
AFX Hardware and Software Requirements 119
Storage 119
Random Access Memory (RAM) 120
Swap Space 120
Processor 120
Disk Partitioning 120
Required Software 120
AFX Port Requirements 120
Nproc Limits for Oracle User (Downloaded Server or Remote Machine) 121
Install AFX 121
Install the AFX Server on an Appliance or a Software Bundle Server Using the Installation Script 122
Install the AFX Server from a Downloaded Local AFX Server 122
Install an Additional New AFX Server Instance on a Non-RSA Identity Governance and Lifecycle Host 123
Install the AFX Server Using an Archive Downloaded from RSA Identity Governance and Lifecycle 123
Install a New AFX Server 123
Install an AFX Server Service 124
Update an AFX Server Installation 125
Install the AFX Connector Packages 126
Download an AFX Server Archive 126
Start the AFX Server 127
Stop the AFX Server 127
Update ActiveMQ Settings 127
Appendix A: Security and Authentication Management (RSA Appliance and Software

Bundle) 129
Working with Keystores and Certificates 129
Keytool 130
Ciphers 130
Managing the Keystore 131
List Your Certificates in the Keystore 131
Change the Default Aveksa Keystore Password 131
Change the Truststore Password 132
Back Up and Restore Default HTTPS Certificates 133
8
Migrating Certificates to SHA-256 134
Migrate the RSA Identity Governance and Lifecycle Server Certificate to SHA-256 134
Configure SSL for a Collector Endpoint 134
Establishing a Secure LDAP/AD Connection for a Data Collector 135
Export the Application Server's Public Certificate 136
Import LDAP/AD system Certificates into the Truststore 136
Appendix B: Troubleshooting 137
Troubleshooting an RSA Appliance or Software Bundle 137
Overview 137
Installation 138
Start Up 139
Runtime 140
Certificate and Keystore Management 141
Troubleshooting a WebSphere Installation 145
Overview 145
Deployment 145
Start Up 146
Runtime 150
Post-Deployment or Upgrade of RSA Identity Governance and Lifecycle 150
Troubleshooting a WebLogic Installation 151
Overview 151
Deployment 152
Start Up 153
Runtime 155
Post-Deployment of RSA Identity Governance and Lifecycle 155
Troubleshooting AFX 156
Start Up 156
Appendix C: Maintenance 161
Maintaining an RSA Appliance or Software Bundle 161
Back Up the RSA-Supplied Database 161
Import the AVUSER Schema/Data for a Database Restoration/Load 163
Validate Compatibility of the Database Import 165
Migrating the Database 166
9
Operating System Installation and Upgrade 167
Operating System Installation Requirements 168
Operating System Installation Prerequisites 168
Determine and Record SLES 11 System Details 169
SLES 11 System Details Worksheet 169
Get the Operating System Installation Software and Create the Installation DVD 169
Install the Operating System from the Installation DVD 170
Configure a Network Bond on a Hardware Appliance 170
Firewall Configuration for SUSE 171
Firewall Configuration for Red Hat 172
Mount an External Drive 174
Check for Running Tasks on an Appliance or Server 175
Determining the Oracle ASM Partition 175
Customize RSA Identity Governance and Lifecycle 176
Starting and Stopping RSA Identity Governance and Lifecycle Services 177
Starting RSA Identity Governance and Lifecycle Services 177
Stopping RSA Identity Governance and Lifecycle Services 177
Starting and Stopping the Oracle Database and Oracle Services 177
Backing Up and Restoring RSA Identity Governance and Lifecycle Software 178
Back up the RSA Identity Governance and Lifecycle Application 178
Restore RSA Identity Governance and Lifecycle 179
Updating Database Hostname References 180
Changing Database User Passwords 180
Changing the Statspack User Name 182
Creating a Heap Dump File 183
Pruning the Job Statistics Table 183
Prune the Statistics Table from the Monitoring Page 183
Changing Server Hostname and Network Settings 184
Uninstalling RSA Identity Governance and Lifecycle 185
Configuring the Test Authentication Module 185
Maintaining a WebSphere Installation 188
Accessing RSA Identity Governance and Lifecycle 188
Modifying the RSA Identity Governance and Lifecycle Enterprise Archive 188
10
Check for Running Tasks in RSA Identity Governance and Lifecycle 189
Configure Non-SSL Port for WebSphere 189
Localization Configuration 190
Changing Database User Names in RSA Identity Governance and Lifecycle 191
Changing Database Tablespace Names in RSA Identity Governance and Lifecycle 191
Changing Database User Passwords in RSA Identity Governance and Lifecycle 192
Updating RSA Identity Governance and Lifecycle on WebSphere with a Patch 193
Uninstalling RSA Identity Governance and Lifecycle from WebSphere 193
Maintaining a WebLogic Installation 196
Accessing RSA Identity Governance and Lifecycle 196
Starting and Stopping RSA Identity Governance and Lifecycle in WebLogic 196
Check for Running Tasks in RSA Identity Governance and Lifecycle 196
Restarting WebLogic 197
Modifying the RSA Identity Governance and Lifecycle Enterprise Archive 197
Configure a Non-SSL Port for WebLogic 197
Localization Configuration 198
Changing Database User Schema Names in RSA Identity Governance and Lifecycle 198
Changing Database Tablespace Names in RSA Identity Governance and Lifecycle 199
Changing Database User Passwords in RSA Identity Governance and Lifecycle 200
Changing the Security Realm User and Group Information 200
Updating RSA Identity Governance and Lifecycle on WebLogic with a Patch 201
Uninstalling RSA Identity Governance and Lifecycle from WebLogic 202
Uninstall AFX using the Uninstall Script 203
Uninstall AFX from an AFX Server Archive 204
Verify the Installation 205
11
Preface
About This Guide
This guide provides instructions for installing and configuring RSA Identity Governance and Lifecycle7.2.1. It is
intended for administrators and other trusted personnel.
Documentation Set
The latest product documentation is always available at

https://community.rsa.com/community/products/governance-and-lifecycle.
Document Description
Release Notes What's new in the release, fixed issues, known issues and workarounds.
Installation Guide Product installation instructions.
Upgrade and Migration Guide Instructions for upgrading your product version and data.
Database Setup and Management Instructions for setting up and managing a customer-supplied Oracle
Guide database for RSA Identity Governance and Lifecycle.
Instructions to set up and configure a WildFly application server cluster
Configuring WildFly Clusters
in an RSA Identity Governance and Lifecycle deployment.
Online Help All concepts and instructions you need to configure and use the product.
How to configure and manage RSA Identity Governance and Lifecycle.
Administrator's Guide
Contains a subset of the information provided in the Online Help.
Public Database Schema Reference The public view of the database schema.
Support and Service
You can access community and support information on RSA Link at

https://community.rsa.com/community/products/governance-and-lifecycle. RSA Link contains a
knowledgebase that answers common questions and provides solutions to known problems, product
documentation, community discussions, and case management.
You can also access the RSA Identity Governance and Lifecycle community at
https://community.rsa.com/community/products/governance-and-lifecycle/client-partner-community. This
private community is only available to RSA Identity Governance and Lifecycle customers, partners, and internal
RSA staff.
12 Preface
Chapter 1: Installation Scenarios

This guide provides instructions for a new installation. If you are upgrading an existing installation, see the RSA
Identity Governance and Lifecycle Upgrade and Migration Guide. RSA Identity Governance and Lifecycle
supports the following installation scenarios.
Scenario Description
RSA-supplied hardware with all required components (operating system, database,
RSA Appliance application server and RSA Identity Governance and Lifecycle) pre-installed. Provides
an Oracle database.
RSA Identity Governance and Lifecycle software installed on customer-supplied
hardware that meets minimum physical requirements and runs a supported operating
system. The software bundle installation includes the application server and RSA
Software Bundle
Identity Governance and Lifecycle. It can also support an RSA-provided Oracle
database, or you can use your own Oracle database. This option is also commonly
referred to as the Soft Appliance.
RSA Identity Governance and Lifecycle OVA deployed on customer-supplied hardware
that meets minimum physical requirements. The virtual application installation
Virtual Application includes the application server and RSA Identity Governance and Lifecycle. Virtual
application installations require a customer-supplied database. RSA recommends that
the customer-supplied database runs on physical hardware.
An RSA Identity Governance and Lifecycle instance running as an application on a
WebSphere server. You deploy RSA Identity Governance and Lifecycle in your
WebSphere
environment, which includes other components that you supply, including a customer-
supplied Oracle database.
An RSA Identity Governance and Lifecycle instance running as an application on a
WebLogic server. You deploy RSA Identity Governance and Lifecycle in your
WebLogic
environment, which includes other components that you supply, including a customer-
supplied Oracle database.
AFX automates the access request fulfillment process by executing the fulfillments at
Access Fulfillment
the target endpoints. For AFX installation scenarios and information on installing AFX,
Express (AFX)
see AFX Installation.
For each scenario, this guide provides guidance for typical enterprise deployments up to 500 concurrent users,
up to 1000 applications, and up to 20 million entitlements.
Application Server Cluster Support for RSA Appliance and Software

Bundle
RSA Identity Governance and Lifecycle supports WildFly application server clustering for the RSA Appliance and
Software Bundle, similar to previous releases for WebSphere and WebLogic installations. This support means
you can set up the following clustered scenarios:
l RSA Appliance. You can add multiple Software Bundles with an RSA Appliance. The Software Bundles
use an RSA-provided database on the RSA Appliance.
Chapter 1: Installation Scenarios 13

l Software Bundle. You can install multiple Software Bundles that use the same customer-supplied
database.
For more information, see the RSA Identity Governance and Lifecycle Solution Integration Guide: Configuring
Wildfly Clustering.
14 Chapter 1: Installation Scenarios

Chapter 2: Installation Prerequisites
Supported Environments and Components
The RSA Identity Governance and Lifecycle Platform Datasheet and Support Matrix for each version is available
on RSA Link (https://community.rsa.com/). This document contains the most current details of the supported
environments and components, including supported browsers and browser configurations.
Note: Internet Explorer 11 using Compatibility View is not supported. Internet Explorer 11 running Enterprise
Mode cannot access RSA Identity Governance and Lifecycle.
Port Requirements
RSA Identity Governance and Lifecycle uses the following ports:
Port Use
21 FTP connections. Can be used to transfer collection data.
22 SSH connections
1158 Oracle Enterprise Manager Express
1555 Oracle Listener for the AVDB data source
Secure connection (using Secure Sockets Layer (SSL) and secure cookies)
8443
when you access RSA Identity Governance and Lifecycle. (default)
Secure communication between the RSA Identity Governance and Lifecycle
8444 application server and external components such as the remote agent and
AFX.
Internal communication. You might need to configure this port when RSA
Identity Governance and Lifecycle is installed on WebLogic or WebSphere.
8080
For more information, see Configuring Non-SSL Port Assignments for
WebLogic or Configuring Non-SSL Port Assignments for WebSphere.
Remote Agent Requirements
An RSA Identity Governance and Lifecycle agent is software that runs on the data collection hosts and manages
the connection to RSA Identity Governance and Lifecycle. Agents may be required to be installed and configured
on remote machines due to network access restrictions that prevent the server-based agent from
communicating directly with data sources.
Remote agent installation is supported on the following operating systems:
l SUSE Linux Enterprise Server 12 SP2

l SUSE Linux Enterprise Server 11 SP3
l Windows Server 2012 R2 64-bit
l Windows Server 2008 R2 64-bit

If an agent is installed on a remote machine, you must do the following:
1. Configure the agent and RSA Identity Governance and Lifecycle to use SSL for secure communication.
For more information, see Check Settings for Secure Communication Ports (SSL/TLS).
2. Edit the agent configuration file to change the hostname from localhost to the hostname of the RSA
Identity Governance and Lifecycle server, or in a clustered environment, the System Operations Node
(SON).
Verify Prerequisites for a Customer-Supplied Database
You must provide your own database for WebLogic or WebSphere environments. In a software bundle or virtual
application deployment, you may either provide your own database or install the RSA-provided database on a
separate machine from the RSA Identity Governance and Lifecycle installation.
If you plan to use your own database, see the RSA Identity Governance and Lifecycle Database Setup and
Management Guide for instructions.
Note: RSA recommends installing the Oracle database on physical hardware rather than in a virtualized
environment. If you do install the database in a virtualized environment, ensure that the virtual machine is
marked dedicated and that the overall virtual machine server has sufficient memory and space. For more
information, reference Oracle's documentation about hosting a virtualized database.
Plan the Customer-Supplied Database Configuration

The RSA Identity Governance and Lifecycle installation prompts you for configuration parameters when you
select the customer-supplied database option.
Record the following parameters for your installation of Oracle 12.1.0.2:
Parameter System information

Oracle
listener
hostname
Oracle
listener
port
number
Oracle SID
Use the following table to record additional configuration parameters listed in the next table if your installation
meets any of the following conditions:
l You are installing a software bundle and the Oracle 12.1.0.2 database uses an Oracle Service Name that
is different than the Oracle SID.
l You are installing RSA Identity Governance and Lifecycle on WebLogic server.
l You are installing RSA Identity Governance and Lifecycle on WebSphere server.

Oracle Service Name
AVUSER user name (RSA Identity Governance and Default is: avuser
16 Chapter 2: Installation Prerequisites


Lifecycle user)
AVUSER password
AVDWUSER user name (RSA Identity Governance
Default is: avdwuser
and Lifecycle reporting engine user)
AVDWUSER password
ACMDB user name (RSA Identity Governance and
Default is: acmdb
Lifecycle public database schema user)
ACMDB password
PERFSTAT user name (RSA Identity Governance and
Lifecycle Statistics Report user)
Default is: perfstat
Note: The PERFSTAT user is optional, however it is
required for gathering database statistics under
System Diagnostics.
PERFSTAT password (or AVPERF)
Note: If you created the database instance with non-default names for the database users, you must use the
same usernames and passwords when prompted during installation.
Verify Prerequisites for an RSA Appliance
The RSA Appliance contains RSA Identity Governance and Lifecycle pre-installed. Verify that you have all of the
necessary components.
RSA Appliance Components

This section lists the hardware and software components that ship with the RSA Identity Governance and
Lifecycle appliance.
Supplied Hardware Components
RSA provided you with one of the following Dell server models: the R640 or R730.
The following items are also provided:
l Power cord
l Ethernet cables (2)
l Bezel and rails
l Cat-5 network cables (2)
Supplied Software Components
RSA Identity Governance and Lifecycle7.2.1 is pre-installed on the RSA Appliance. The following additional
software components are also pre-installed:
Component Product and Version

Operating System SUSE Linux Enterprise Edition 12 SP4
Database Oracle 12.1.0.2 Enterprise Edition

Component Product and Version

Application Server WildFly 10
Java AdoptOpenJDK 1.8
Additional Required Hardware Components
You must provide the following additional items:
l Monitor
l Keyboard
l Crossover cable
Font Requirement
Before you install RSA Identity Governance and Lifecycle, ensure that DejaVu Fonts are available on the system.
RSA Identity Governance and Lifecycle requires these fonts for reporting.
Software Bundle Requirements
Verify that the hardware on which you plan to install RSA Identity Governance and Lifecycle meets the hardware,
software, and network requirements listed in the following sections.
Hardware Requirements for the Software Bundle

RSA Identity Governance and Lifecycle has the following hardware requirements.
Component Production Minimum Requirements

48 GB with RSA-supplied database
RAM
16 GB with customer-supplied database
Processor Dual Intel E5-2400 Quad Core
l 1 TB + (RAID 1 or RAID 5)
Disk Space l 16 GB minimum required for /root volume
Installation script checks for swap space to be at least 16 GB.

Network Bond of NICs in active-backup bond mode
If you are installing Access Fulfillment Express (AFX), you need additional disk space for AFX software,
connectors, and log files. The following table lists the AFX requirements.
Component Disk Space Required

AFX Installation 5 GB
Log 10 MB for each connector
Connector 5 MB for each connector
The installation script checks disk space for these partitions:
Partition Disk Space Required Reason

AVEKSA_HOME 6.5 GB ACM installation
ORACLE_BASE 13.5 GB Local Oracle installation
/tmp 7 GB Installation explodes the ear in /tmp

Note: If the AVEKSA_HOME and ORACLE_BASE partitions share the same volume, they require 20 GB disk
space in total.
Operating System Requirements for the Software Bundle

RSA Identity Governance and Lifecycle requires one of the following operating systems:
Operating System Patch Level

SUSE Linux Enterprise
SP2, SP3, or SP4; 64-bit
Server 12
Red Hat Enterprise Linux 7 Minor version 2 or higher; 64-bit
Note: RSA Identity Governance and Lifecycle7.2.1 does not support Red Hat Enterprise Linux version 5.x or
6.x. Customers who have existing deployments on Red Hat Enterprise Linux 5.x must upgrade to a supported
operating system.
Note: RSA Identity Governance and Lifecycle software bundles using an RSA-supplied database do not support
automatic storage management (ASM).
Required Packages
Verify that required Oracle packages are installed on the same machine as the RSA Identity Governance and
Lifecycle software.
l See the "Package Requirements for Oracle Management Service" section at

http://docs.oracle.com/cd/E29505_01/install.1111/e22624/preinstall_req_packages.htm
l See the "Configuring Operating Systems for Oracle Grid Infrastructure and Oracle RAC" section at
http://docs.oracle.com/database/121/CWLIN/prelinux.htm#CWLIN168
The following packages are required for Red Hat Enterprise Linux 7.2+ environments, and may need to be
explicitly installed in addition to the operating system.
l compat-libstdc++-33-3.2.3-72.el7.x86_64
l javapackages-tools
l bea-stax-api
l binutils-2.27-27.base.el7.x86_64
l compat-libcap1-1.10-7.el7.x86_64
l gcc-4.8.5-28.el7.x86_64
l gcc-c++-4.8.5-28.el7.x86_64
l glibc-2.17-222.el7.x86_64
l glibc-devel-2.17-222.el7.x86_64
l ksh
l libaio-0.3.109-13.el7.x86_64
l libaio-devel-0.3.109-13.el7.x86_64
l libgcc-4.8.5-28.el7.x86_64,libgcc
l libstdc++-4.8.5-28.el7.x86_64
l libstdc++-devel-4.8.5-28.el7.x86_64
l libXi-1.7.9-1.el7.x86_64
l libXtst-1.2.3-1.el7.x86_64

l make-3.82-23.el7.x86_64
l sysstat-10.1.5-13.el7.x86_64
l lcms2
l rhino
Customer-Supplied Database Requirements for the Software Bundle

If you are installing RSA Identity Governance and Lifecycle and you are not installing the RSA-supplied database,
you must provide your own installation of Oracle 12.1.0.2. You are prompted to specify the database during the
RSA Identity Governance and Lifecycle installation. For more information, see Verify Prerequisites for a
Customer-Supplied Database and the Database Setup and Management Guide.
Time Server Requirement for the Software Bundle

Verify that a valid Network Time Protocol (NTP) server is available for RSA Identity Governance and Lifecycle.
You are prompted to provide the IP address of the NTP server during installation.
Font Requirement
Virtual Application Requirements
Verify that the environment in which you install the RSA Identity Governance and Lifecycle virtual application
meets the requirements listed in this section.
You can install the RSA Identity Governance and Lifecycle virtual application using VMware ESXi version 5.x or
higher.
Note: The following tables describe the minimum requirements for the virtual application. The hardware on
which the virtual application is deployed should exceed these minimums to ensure proper performance.
Component Production Minimum Requirements

CPUs 4 CPUs
16 GB
RAM Installation script checks for 4GB and minimally 50 MB free for installation; swap space up to 16
GB.
Processor Dual Intel E5-2400 Quad Core
l 1 TB + (RAID 1 or RAID 5)
Disk Space
l 16 GB minimum required for /root volume
Network Bond of NICs in active-backup bond mode
If you are installing Access Fulfillment Express (AFX), you need additional disk space for AFX software,
connectors, and log files. The following table lists the AFX requirements.
Component Disk Space Required

AFX Installation 5 GB
Log 10 MB for each connector
Connector 5 MB for each connector

The installation script checks disk space for these partitions:
Partition Disk Space Required

/root 5.1 GB
/home 1 GB
/home/oracle 5.2 GB
/u01 6.5 GB
Note: If the /home partitions share the same volume, they require 7.2 GB disk space in total.
Virtual application deployments require the Oracle database to be installed on a separate machine. For more
information, see Database Requirements for the Virtual Application on page 21.
Database Requirements for the Virtual Application

If you are installing RSA Identity Governance and Lifecycle on a virtual application, you must deploy and
configure an instance of Oracle 12.1.0.2 Enterprise Edition separately from the virtual application.
RSA recommends that you deploy the database in a physical, rather than virtualized, environment. You are
prompted to specify the database during RSA Identity Governance and Lifecycle installation.
You can do one of the following:
l Supply your own database that meets the requirements described in the RSA Identity Governance and
Lifecycle Database Setup and Management Guide.
l If licensed, download the RSA-provided database-only installation file RSA_IGL_
DatabaseOnly.tar.bz2 from RSA Link, which creates a standalone Oracle database server that is
configured with the appropriate tablespace, users, and schema for RSA Identity Governance and
Lifecycle.
The RSA-provided standalone database must be installed on a machine running the SLES 12 SP2, SP3,
or SP4, or RHEL 7.2+ operating systems.
The database requires a minimum of 32 GB memory.
Time Server Requirement for the Virtual Application

Verify that a valid Network Time Protocol (NTP) server is available for RSA Identity Governance and Lifecycle, to
ensure that the time between the virtual application, database server, and any other connected systems are
synchronized. You are prompted to provide the IP address of the NTP server during virtual application setup.
Font Requirement
Verify Prerequisites for WebSphere
The WebSphere application server where you install or upgrade RSA Identity Governance and Lifecycle must
meet the following requirements.
Component Requirement
Either of the following:
WebSphere Version
l IBM WebSphere Application Server Edition 8.5.5.x or 9.0

l IBM WebSphere Application Server Network Deployment Edition 8.5.5.x or 9.0
Production minimum requirement: 32 GB
RAM Note: You must allocate at least 8 GB of RAM to the RSA Identity Governance and
Lifecycle server.
Operating System An operating system that supports WebSphere
An Oracle 12.1.0.2 instance configured to support RSA Identity Governance and
Lifecycle.
For more information about database requirements, see Verify Prerequisites for a
Database
Customer-Supplied Database on page 16.
For instructions on configuring the customer-supplied database, see the Database

Setup and Management Guide.
Disk Space 600 MB available for RSA Identity Governance and Lifecycle
Java IBM JDK 1.7 (supported, but deprecated) or 1.8 (recommended)
Customer-Supplied Database Configuration for WebSphere Installations

You need the following information about the database configuration before you install RSA Identity Governance
and Lifecycle. Obtain this information from the database administrator.
RSA Identity Governance and Lifecycle schema user (AVUSER):

RSA Identity Governance and Lifecycle reporting engine schema user (AVDWUSER):
RSA Identity Governance and Lifecycle public database schema user (ACMDB):
AVUSER password:
ACMDB password:
AVDWUSER password:
AVPERF username/password:
Oracle Database SID:
Oracle Host listener: (Use the Fully Qualified Domain Name (FQDN) or IP address of the Oracle host.)
Oracle Listener Port:
Distribution path for RSA Identity Governance and Lifecycle software:
WebSphere Application Server Requirements

The WebSphere application server instances must meet the following requirements:
l The application server instances (nodes) must have the configured Java language as en_US.
l RSA recommends that the RSA Identity Governance and Lifecycle application is the sole application
running on a server instance to ensure that the memory requirements are met.
l In a clustered environment, each node must be on a separate machine.
l In a clustered environment, each node must have a unique name. The display name of the server
instance in WebSphere is used as the unique node name in RSA Identity Governance and Lifecycle.
l In a clustered environment, record the following information for each node:
l Machine name
l Node name

l Server name
l Bootstrap address
Font Requirement
Verify Prerequisites for WebLogic
The WebLogic application server where you install or upgrade RSA Identity Governance and Lifecycle must meet
the following requirements.
WebLogic Version 12.1.x or 12.2.x
Production environment: 32 GB
RAM Note: You must allocate at least 8 GB of RAM to the RSA Identity Governance and
Lifecycle server.
Operating System An operating system that supports WebLogic
An Oracle 12.1.0.2 instance configured to support RSA Identity Governance and
Lifecycle.
For more information about database requirements, see Verify Prerequisites for a
Database
Customer-Supplied Database on page 16.
For information about configuring the customer-supplied database, see the Database
Setup and Management Guide.
Disk Space 600 MB available for RSA Identity Governance and Lifecycle
Java Oracle JDK 1.7 (supported, but deprecated) or 1.8 (recommended)
Customer-Supplied Database Configuration for WebLogic Installations

You need the following information about the database configuration before you install RSA Identity Governance
and Lifecycle. Obtain this information from the database administrator.
AVUSER password:
ACMDB password:
AVDWUSER password:
AVPERF username/password:
Oracle Database SID:
Oracle Host listener:
Oracle Listener Port:
Distribution path for RSA software:
In a clustered environment, the following information is also required for each node in the cluster.
Server node name:

Listening address:
Listening port:

You can see the server information in the WebLogic Administration Console under Environment > Servers.
WebLogic Application Server Requirements

The WebLogic application server instances must meet the following requirements:
l The application server instances (nodes) must have the configured Java language as en_US.
l RSA recommends that the RSA Identity Governance and Lifecycle application is the sole application
running on a server instance to ensure that the memory requirements are met.
l In a clustered environment, each node must be on a separate machine.
l In a clustered environment, each node must have a unique name. The display name of the server
instance in WebLogic is used as the unique node name in RSA Identity Governance and Lifecycle.
l In a clustered environment, record the following information for each node:
l Server node name

l Listening address
l Listening port
Font Requirement

Chapter 3: RSA Appliance Installation

Installing the RSA Appliance consists of the following tasks:
1. Install the Appliance

2. Configure Appliance Network Settings
3. Log on to RSA Identity Governance and Lifecycle
4. Apply the Latest Operating System and Database Patch Updates to an Appliance
5. Confirm the Setting for the Encryption Key Directory
6. Implement Security Best Practices
Install the Appliance
Before You Begin

To our legacy customers with existing hard appliance with RHEL5u8 OS with prior 7x versions of ACM, please
review the following documents before you begin:
l Appliance Updater Guide
l Upgrade and Migration Guide
l Platform Support Matrix documents
We no longer provide hard appliance with the Red Hat operating system. All our hard appliances are
preconfigured and shipped with SUSE (SLES 12) OS. Please contact support for EOPS Policy and extended
support.
Verify the hardware, software, and database requirements described in Chapter 2, Installation Prerequisites.
Procedure
1. Using the provided rack and bezel, install the appliance hardware in a secure area.
2. Attach a keyboard and monitor to the appliance.
3. Plug in and power on the appliance.
Note: The operating system is pre-installed on the RSA Appliance. If you need to re-install and configure the
SUSE operating system, see the Operating System Installation Overview section in Appendix C.
Configure Appliance Network Settings
Before You Begin

Collect the information necessary to configure the appliance network settings:
l IP address and host name

l Domain Name Servers (DNS)

l Time zone in which the appliance is located
Refer to the Appliance Network Configuration sheet that shipped with the appliance for this information. You
may still need, or want, to modify this configuration information.
Procedure
1. Log on to the appliance in one of the following ways:
l Log on using the iDRAC IP address listed on the Appliance Network Configuration sheet.
l Log on and change the default password as follows:
a. At the login as prompt, enter admin.
b. At the password prompt, enter the password provided with the appliance.
c. Change the password after your initial login. Enter
passwd <new password>
where <new password> is the new password that you want to use for the admin account.
2. Change the appliance hostname.

a. If AFX is installed, use the following command to stop the AFX server:
service afx_server stop
b. Log on as root.
c. Stop the RSA Identity Governance and Lifecycle service. Enter
service aveksa_server stop
d. Start the Oracle database. Enter
service aveksa_server startoracle
e. Change the hostname. Change directory to /home/oracle/deploy/bin, then enter
bash modifyhostname.sh <hostname.domain name>
where <hostname.domain name> is the new name of the appliance.
The modifyhostname.sh script re-creates the server-side certificates with the new hostname. If
the installation includes the AFX module, you must re-create its client certificates to include the
new hostname. For more information, see Change an AFX Server SSL Certificate in the Help.
3. Stop the Oracle database. Enter
service aveksa_server stoporacle.
4. Configure the domain name servers.

a. Enter
bash setnameserver.sh <ns1> <ns2>
where <ns1> is the first name server and <ns2> is the backup name server.
26 Chapter 3: RSA Appliance Installation

b. Verify the name server address. Enter
cat /etc/resolv.conf
5. Configure the network settings. Enter
bash modifynetworksettings.sh <IP> <Netmask> <Gateway>
Where:
l <IP> is the IP address of the appliance
l <Netmask> is the subnet mask
l <Gateway> is the network gateway
6. Set the time zone where your appliance is located. Enter
setlocaltime <timezone>
where <timezone> is the abbreviation of a country and city in the same geographic location as the
appliance. For a list of valid time zone abbreviations, see /usr/share/zoneinfo.
For example, to set the time zone for an appliance located in New York, enter
setlocaltime America/New_York
7. Reboot the appliance. Enter
reboot
8. After reboot, you must restart Oracle database services and RSA Identity Governance and Lifecycle.
Enter
service aveksa_server startoracle
service aveksa_server start
If AFX is installed, also enter:
service afx_server start
You can now log on to RSA Identity Governance and Lifecycle.
Log on to RSA Identity Governance and Lifecycle
You can log on to RSA Identity Governance and Lifecycle from any compatible Web browser.
The first time a system administrator logs on to the RSA Identity Governance and Lifecycle user interface, to
agree to the license, he or she must enter the Customer ID, Customer Name, and System Type. The
Customer ID value is provided by RSA and is provided to all customers through email. These values are logged
under diagnostic and system data.
Procedure

1. On the appliance, open a browser, then enter the following URL:
https://<installation machine IP address>
The RSA Identity Governance and Lifecycle Login screen appears.
2. Enter AveksaAdmin in the User Name field.
AveksaAdmin is the name of the administrator (super user) in the RSA Identity Governance and Lifecycle
system.
3. Enter aveksa123 in the Password field.
4. On the License Agreement screen, enter the following details:
l Customer ID, which is provided by RSA and is provided to all customers through email.
l Customer Name, which is used in diagnostic and system data to identify the system.
l System Type indicates whether the system is for production purposes.
Then click OK.
5. When prompted, enter the new password for the AveksaAdmin user in the New Password box.
The password must contain at least eight characters, including one upper and one lower case character,
and one number.
6. Re-enter your new password in the Confirm Password box.
7. Click OK.
Apply the Latest Operating System and Database Patch Updates to

an Appliance
The appliance updater does not patch the RSA Identity Governance and Lifecycle application.
It is important to keep the operating system and database components of an RSA Identity Governance and
Lifecycle appliance up-to-date with the latest patches. RSA provides the Appliance Updater to achieve that goal.
It bundles a certified patch set for the operating system of an RSA appliance and the database on the appliance.
Downloading and running these patches closes vulnerabilities and addresses bugs.
The patches are provided in a compressed file (rsaimg_updater_<release_date>_<platform>.tar.bz2) and

posted on RSA Link at https://community.rsa.com/community/products/governance-and-lifecycle.
Download and apply the appliance updater patches on a regular basis as new patches are released.
For more information, see the RSA Identity Governance and Lifecycle Appliance Updater Guide.
Confirm the Setting for the Encryption Key Directory
The Key Encryption Key (KEK) is the key used to encrypt all other encryption keys. After installation (or
upgrade), on first startup of RSA Identity Governance and Lifecycle, a unique KEK is created and stored in the
encryption key directory. The default location of the directory is /home/oracle/security. If the default directory

is not available or you want to set a different directory, you must create the directory, and then specify the
location in a Java system variable.
Procedure
1. Log in as root.
Note: You must log in as the root account to ensure that the proper permissions are granted. This
procedure may not work using any other account.
2. Make sure you have a directory for storing the encryption key. For security purposes, the directory
should have the following settings:
l If the directory already exists, set its permissions to 700 (rwx------) and make sure that the
directory is owned by the same user under which RSA Identity Governance and Lifecycle is
running.
l If the directory does not exist, the parent directory must be writable for the user under which
RSA Identity Governance and Lifecycle is running. In this case, RSA Identity Governance and
Lifecycle will create the directory with the correct permissions.
l For a cluster, this same directory also needs to exist on each of the nodes.
3. Confirm that the Java system property "rsavialg.security.keydir" is set to the appropriate directory. Use
the steps for your platform in the following table to confirm or add the setting.
Platform: Instructions:
The property is in aveksa-standalone-full.xml
(/home/oracle/wildfly/standalone/configuration/aveksa-standalone-full.xml):
<system-properties>
Standalone <property name="rsavialg.security.keydir" value="/home/oracle/security"/>
</system-properties>
The default value for the directory is "/home/oracle/security" Change this to the directory
where you will store the encryption key.
On the Domain Controller, the property is in domain.xml
(/home/oracle/wildfly/domain/configuration/domain.xml). Set the following values:
<system-properties>
<property name="rsavialg.security.keydir" value="/home/oracle/security"/>
Cluster </system-properties>
The default value for the directory is "/home/oracle/security" You should change this to the
directory where you will store the encryption key
The setting on the domain controller will be propagated to the other nodes in the cluster.
Make sure you have the same encryption key directory on each of the nodes.
4. Create a secure backup process to back up the keys in the encryption key directory. RSA Identity
Governance and Lifecycle generates these keys and stores them only in the designated directory.
If the keys are lost, any data encrypted with those keys will be irrecoverable. The backup process should
ensure that the keys are not compromised during the backup or after they are in the backup location.
Note: Anytime that you change the value of the Java system property after the keys have already been created
(meaning after you configured the property and brought the system up), you must bring down the system and
move the keys to the new location before bringing up the system again.

Using Non-restrictive Mode for the Encryption Key Directory

RSA recommends restricting access to the encryption key directory as stated in the previous section. If your
installation cannot restrict the directory to the application owner and permissions as stated, you can implement
a non-restrictive mode by using a Java system property named: rsavialg.security.strict.permissions.disabled .
When "rsavialg.security.strict.permissions.disabled" is set to be “true”, restrictions on who owns the

encryption key directory and what permissions are set on the directory are more flexible, but there are still
requirements for permissions as described below.
Procedure
1. Add the "rsavialg.security.strict.permissions.disabled" property to system properties and set the value
to "true" as shown for the platform type:
Standalone <system-properties>
<property name="rsavialg.security.strict.permissions.disabled" value="true"/>
Cluster <system-properties>
2. Change the "rsavialg.security.keydir" property to the directory you want to use.
l If the directory already exists, set its permissions such that the user (owner of the process
under which RSA Identity Governance and Lifecycle is running) has “rwx” access into this
directory. The owner of the directory need not be the same as the owner of the application
process, but the owner of the application process must be able to read and write into this
directory. This means “rwx” permissions have to be set for the appropriate file permission field
(owner, group, all) , which will allow the application process full access.
l If the directory does not exist, it is recommended that you create it. Set up the permissions on
the directory as specified in the previous item.
l If the directory does not exist and you do not create it, the application will attempt to create the
directory on first startup using default permissions and the directory will be owned by the same
user as the application process.
Note: Any time the value of the "rsavialg.security.strict.permissions.disabled" property is set or

changed, the application server should be restarted.
Note: If "rsavialg.security.strict.permissions.disabled" is set to “false” or you remove this property,

then standard “restrictive” handling for this directory will be used. If you had previously set up the
directory for “non-restrictive” handling and switch to “restrictive” you must ensure this directory is set

up given the requirements outlined in “Confirm the Setting for the Encryption Key Directory” (see
above).
Error Messages
The following table lists error messages that might display (in the AveksaServer.log) after you configure the
encryption key directory. The table lists default directory paths for the master encryption key directory
(/home/oracle/security) and its parent directory (/home/oracle). The suggested actions are performed on the
RSA Identity Governance and Lifecycle host.
Message Description Action

KEK_ERROR_ Create the directory structure, set
PARENT_ The parent directory /home/oracle for the permissions to allow RSA Identity Governance
DIRECTORY_ specified encryption key storage directory and Lifecycle to read from and write to the
DOES_NOT_ /home/oracle/security does not exist. directory, and specify the encryption key
EXIST directory again.
KEK_ERROR_
Change permissions on the specified
PARENT_ The parent directory /home/oracle for the
encryption key directory to allow RSA Identity
DIRECTORY_ specified encryption key storage directory
Governance and Lifecycle to write to the
IS_NOT_ /home/oracle/security is not writable.
directory.
WRITABLE
KEK_ERROR_ The parent /etc/hosts for the specified encryption
Specify a directory path for the encryption
PARENT_IS_ key storage directory /etc/hosts/security is a file,
key directory.
A_FILE not a directory.
KEK_ERROR_
A file already exists with the same path as the
FILE_ Specify a directory location, not a file
specified encryption key storage directory
ALREADY_ location.
/etc/hosts.
EXISTS
KEK_ERROR_ Create the directory, set permissions to allow
COULD_NOT_ Could not create the encryption key storage RSA Identity Governance and Lifecycle to
CREATE_ directory /home/oracle. read from and write to the directory, and
DIRECTORY specify the encryption key directory again.
KEK_ERROR_
Verify that directory permissions allow RSA
DIRECTORY_ The encryption key storage directory
Identity Governance and Lifecycle to write to
IS_NOT_ /home/oracle is not writable.
the directory.
WRITABLE
DIRECTORY_ The encryption key storage directory RSA Identity Governance and Lifecycle to
DOES_NOT_ /home/oracle does not exist. read from and write to the directory, and
EXIST specify the encryption key directory again.
The encryption key storage directory Identity Governance and Lifecycle to write to
KEK_ERROR_ the directory.
/home/oracle must have rwx------ (700)
INVALID_
permissions. Please refer to the installation Alternatively, you can set a system property
DIRECTORY_
documentation for a system property that can be to remove this restriction. See "Using Non-
PERMISSIONS
set to remove this restriction. restrictive Mode for the Encryption Key
Directory" in the previous section.

Implement Security Best Practices
RSA recommends that you follow these security practices:
l Check Settings for Secure Communication Ports (SSL/TLS)

l Set Up a Signed Certificate for HTTPS Access
l Check Security Settings for the RSA Identity Governance and Lifecycle Application
Using a Signed Certificate for HTTPS Access to RSA Identity Governance

and Lifecycle
When you connect to RSA Identity Governance and Lifecycle using a browser, the RSA Identity Governance and
Lifecycle server identifies itself using a certificate. RSA recommends that you use a signed certificate to provide
the most secure communications.
A self-signed certificate is installed with the product. Though the self-signed certificate enables an HTTPS
connection, the client browser will always display a certificate warning before it allows a user to connect.
Replace the self-signed certificate with a certificate signed by a Certificate Authority (CA).
For more information, see Working with Keystores and Certificates.
This section describes how to obtain a CA-signed certificate and use it to identify the server.
You can generate a new request and have the certificate signed by an internal CA, or you can request a server
certificate to be signed by a well-known CA to replace the default RSA Identity Governance and Lifecycle self-
signed server certificate.
Your company might require further configuration for the trusted CA or RSA Identity Governance and Lifecycle
server certificates on the application server.
When using an RSA Identity Governance and Lifecycle server certificate signed by an external or internal CA,
you must add the trusted root CA certificate file to the truststore prior to uploading the server certificate file.
Browsers and application servers often contain CA root certificates from well known CAs. Users may be required
to import the root/intermediate CA certificate file to their web browsers if the CA is not known. See the web
browser documentation for more information.
Follow these steps to generate a signed server certificate:
1. Generate a Key Pair

2. Generate a Certificate Signing Request
3. Import a Trusted Certificate
4. Import Signed Server Certificate into the RSA Identity Governance and Lifecycle Keystore
Step 1: Generate a Key Pair
You can generate a new server certificate that meets your organization’s security requirements and fully
qualified domain name (FQDN). RSA Identity Governance and Lifecycle provides a default certificate with an
alias of “server.” You must define your own alias <server-cert-alias> for your generated server certificate.
You can delete the existing server certificate (the one using the server alias) from the aveksa.keystore file after
generating a new server certificate file in the aveksa.keystore file. Specify the options required for your server
certificate (FQDN, keysize, validity, security algorithms and so on).
Procedure

1. Log on as the oracle user, then go to the keystore directory:
cd /home/oracle/keystore
2. Back up the aveksa.keystore:
cp aveksa.keystore aveksa.keystore.backup
3. Generate a new key pair:
keytool -genkeypair -keysize <keysize> -validity <#days> -alias

<server-cert-alias> -dname <“domain-name”> -keyalg <key algorithm> -
file <Server_cert_file> -storepass <Keystore Password> -keystore
<Keystore File>
For example:
keytool -genkeypair -keysize 2048 -validity 18000 -alias mycorpServer

-dname "CN=acm-
server.mycorp.com,OU=Aveksa,O=MyCorp,L=Waltham,S=Massachusetts,C=US"
-keyalg RSA -keypass Av3k5a15num83r0n3 -storepass Av3k5a15num83r0n3 -
keystore aveksa.keystore
Note: RSA is the recommended key algorithm.
This example defines in the FQDN a server on which RSA Identity Governance and Lifecycle is running, a
key size of 2048, and the length of time the certificate is valid (18000 days or ~50 years). The alias is
myCorpServer.
The alias cannot be the same as the alias used by any existing certificate. The CN value must be the
exact URL from which RSA Identity Governance and Lifecycle is accessed. If RSA Identity Governance
and Lifecycle is accessed from any other address, the certificate does not secure the connection. If the
certificate is accessed from multiple URLs on the same server, a Subject Alternative Name (SAN) must
be provided with all additional URLs when generating the certificate.
Step 2: Generate a Certificate Signing Request
Certificates are trusted if signed by a CA. To obtain a signed certificate, you must first generate a Certificate
Signing Request (CSR) and submit to a CA. The CA returns the signed certificate and any other certificates
(intermediate and root certificates of the CA for example) that may be required for the signing authority to be
trusted.
Procedure
1. Log in as the oracle user, then go to the following directory:
2. Generate the CSR by typing the following command:
keytool -certreq -alias <server-cert-alias> -storepass

Av3k5a15num83r0n3 -file <cert-request-file>.csr -keystore
aveksa.keystore

Note: The CSR file must have the “.csr” extension.
The CSR, acmserver.csr, is sent to a CA to be signed. The CA can be your internal CA or an external
company such as VeriSign. You would typically receive a signed certificate and any root/intermediate
certificates, for example, root.cer, and intermed.cer.
3. Restart RSA Identity Governance and Lifecycle:
acm restart
Step 3: Import a Trusted Certificate
If a certificate is created and signed by an internal or unknown CA, then the certificate chain of the signing CA
must be imported into the truststore. The certificate chain consists of a root certificate and any number of
intermediate certificates used to establish the validation of the signing CA. The certificate chain must be
imported in the correct order starting with the root certificate down the chain of any intermediate certificates.
You need root permissions to perform the task of importing certificates.
Note: The default truststore can be one of the following:
l $JAVA_HOME/jre/lib/security/jssecacerts
l $JAVA_HOME/jre/lib/security/cacerts
l Cacerts referred by your host machine. For example, in Red Hat Enterprise Linux 6, the default
truststore is /etc/pki/java/cacerts.
l Custom truststore which is assigned to the 'javax.net.ssl.trustStore' system property in JAVA_OPTS.
Make sure to copy the trusted certificates to the appropriate truststore.
Procedure
1. Log in as root.
2. Go to the truststore directory. For example:
cd $JAVA_HOME/jre_openjdk/lib/security
where $JAVA_HOME = /etc/alternatives/java_sdk_1.8.0
3. Back up your truststore. For example:
cp cacerts cacerts.backup
4. Import the trusted authority certificate using the keytool:
keytool -import -v -noprompt -trustcacerts -alias <root-tcert-alias>

-file <root_cert_file> -storepass <Keystore Password> -keystore
<Keystore File>
For example:

keytool -import -v -noprompt -trustcacerts -alias ACMEROOT -file

ACME-Root.cer -storepass changeit -keystore cacerts
The following message is displayed:
Certificate was added to keystore.
Repeat these steps to import for any additional intermediate certificates.
acm restart
Step 4: Import a Signed Server Certificate into the RSA Identity Governance and Lifecycle Key-
store
Procedure
1. Log in as the oracle user, then run the following commands:
keytool -import -v -noprompt -trustcacerts -alias <server-cert-alias>

-file <Server_cert_file> -storepass Av3k5a15num83r0n3 -keystore
aveksa.keystore
where
<server-cert-alias> is the alias you specified for the server certificate.
<Server_cert_file> is the signed server certificate file.
2. To verify that RSA Identity Governance and Lifecycle is using the new certificate, enter:
keytool -list -v -storepass Av3k5a15num83r0n3 -keystore

aveksa.keystore
3. In the list of certificates, verify that Certficate[1] uses the alias of the new certificate and that other
certificates listed (Certificate[2], Certificate[3] and so on), are part of the certificate chain of the new
certificate.
4. If Certificate[1] uses the alias of the old certificate, delete the old certificate. Enter
keytool -delete -alias <old-cert-alias> -storepass Av3k5a15num83r0n3

-keystore aveksa.keystore
5. Restart RSA Identity Governance and Lifecycle. Enter
acm restart
6. Verify that the new certificate is used when you access the application through a browser.
a. Log on to the RSA Identity Governance and Lifecycle application.
b. View the certificate information in the browser. Most browsers display a lock icon in the URL bar
that you can click to display certificate and security information.
c. If there is no root certificate, restart RSA Identity Governance and Lifecycle to register the root
certificate.

d. If the certificate information indicates that the root certificate is not trusted, either of the
following conditions may apply:
l The wrong root certificate was imported. In this case, you must obtain the correct root
certificate from the CA, import it into cacert, restore the aveksa.kesytore backup and
perform the steps in Setting Up a Signed Certificate for HTTP Access to RSA Governance
and Lifecycle.
l The signed certificate was imported before the trusted root certificate was imported. In
this case, you must restore the aveksa.kesytore backup and perform the steps in Setting
Up a Signed Certificate for HTTP Access to RSA Governance and Lifecycle.
Check Security Settings for RSA Identity Governance and Lifecycle

RSA Identity Governance and Lifecycle provides security settings that protect against unauthorized access and
cross-site scripting attacks.
To view the settings, in RSA Identity Governance and Lifecycle, click Admin > System, and click the Security
tab.
The Security tab contains the following information:
l Security
l XSS/Scripting Security
l Web Services and Mobile
The default settings comply with security best practices. For information about these settings, click Help on the
Security settings page.
Setting Up User Access to RSA Identity Governance and Lifecycle
RSA Identity Governance and Lifecycle provides a default user named AveksaAdmin. To provide access to other
users, you can define:
l A single sign-on (SSO) source.

l An LDAP-compliant authentication source, for example an Active Directory server. In this case, RSA
Identity Governance and Lifecycle collects account or identity data for all users who require access. You
must configure the account or identity collectors.
For instructions on setting up an authentication source, see Managing Log On Authentication Sources in Help.

Chapter 4: Software Bundle Installation

Perform the following tasks to install the Software Bundle:
1. Download the Installation Files

2. Copy the Downloaded Installation Files to the Installation Host
3. Run the Installation Script
l Perform the Installation as the Root User on page 40
l Perform Installation as the Oracle User on page 42
4. Open Ports on the Firewall

5. Log on to RSA Governance and Lifecycle
6. Apply the Latest Updates to a Software Bundle
7. Confirm the Settings for the Encryption Key Directory
Download the RSA Identity Governance and Lifecycle Installation

Files
Before You Begin
l Verify the hardware, software, and database requirements described in Chapter 2, Review Installation
Prerequisites.
l You must have a valid license for RSA Identity Governance and Lifecycle.
Procedure
1. Download the following installation files:
a. Go to RSA Link (https://community.rsa.com/community/products/governance-and-lifecycle),
then click Log In and enter your user name and password.
b. Click RSA Identity Governance and Lifecycle.
c. Click Downloads > RSA Identity Governance and Lifecycle 7.2.1.
d. Click Version Upgrades.
e. Click the Upgrade link for your licensed RSA Identity Governance and Lifecycle asset.
f. Click Continue.
g. On the Order Detail page, click the menu icon and select Product List.
The Current tab lists the most recent release. The Archive tab lists previous releases.
h. Click RSA Identity Governance and Lifecycle Version 7.2.1.

i. Download the following files:
l wildfly-10.1.0.Final.tar
l adoptjdk_8u252b09.tar.gz
l aveksa-<product-version>.tar.bz2

2. If you are using an RSA-supplied database, go back one screen, select Hardware Appliance Version
7.2.1, then download these files:
l linuxamd64_12102_database_1of2.zip
l linuxamd64_12102_database_2of2.zip
l linuxamd64_12102_grid_1of2.zip
l linuxamd64_12102_grid_2of2.zip
l oracle_12.1.0.2_patches_v001.zip
l asmlib-008_x64.tar.bz2
l cvupack_Linux_x86_64.zip
3. Download the appliance updater file for your installation:

l rsaimg_updater_<release_date>_<platform>.tar.bz2.
Copy the Installation Files to the Installation Host
Procedure
1. Log in to the host as root or another user that is performing the installation.
Note: You are not required to use root, however non-root users are not able to update the sudoers file
or create a system service to start and stop the application. The application does not require a system
service to start and stop. The root user may be necessary to install the prerequisite JDK.
2. Create a directory for the packages. By default, this is /tmp/aveksa/packages. For example:
mkdir -p /tmp/aveksa/packages
Note: If the directory already exists, delete any files in the directory before you proceed.
3. Copy the downloaded installation package files to the directory.

4. Verify that the compressed package files you downloaded were not corrupted during the file transfer.
Run the following commands in the /tmp/aveksa/packages directory:
l tar -jtvf on all downloaded .tar.bz2 files. For example:
tar -jtvf asmlib-008_x64.tar.bz2
l unzip -t on all downloaded .zip files. For example:
unzip -t linuxamd64_12102_database_1of2.zip
The commands list the packages and indicate if errors were detected.
5. If it already exists in your environment, delete the directory where the RSA Identity Governance and
Lifecycle installation and product files are staged. For example:
/tmp/aveksa/staging
38 Chapter 4: Software Bundle Installation

6. Expand the Aveksa package in a new staging directory, referred to in the following example as <aveksa_
staging_directory>. This can be any directory except in a hardware appliance, in which the
/tmp/aveksa/staging directory is required. For example:
mkdir -p <aveksa_staging_directory>
cd <aveksa_staging_directory>
tar <product_version>.tar.bz2
Perform the Installation
Depending on your environment and requirements, you can run the installation script as either the root user or
oracle user.
l Perform the Installation as the Root User on page 40. Use this method in the following scenarios:
l You are using an RSA-supplied database.
l You want to install the RSA Identity Governance and Lifecycle application as a service.
Note: The root user can install RSA Identity Governance and Lifecycle either as a service or a
non-service.
l You need to use sudo functionality.
l Perform Installation as the Oracle User on page 42. Use this method in the following scenarios:
l You are using a remote database and you do not need to install services or use sudo
functionality.
The following flowchart illustrates the overall installation process for each option.

Perform the Installation as the Root User

The installation script performs checks for the following installation requirements:
l Memory
l Disk space for partitions
l Operating system packages
l Network settings
l User and group settings
l System configurations

The script displays information about the checks, and it indicates if a requirement is not met. After you resolve
the requirement, you can run the script again.
Installation scripts and any installation errors are recorded in the install log (/tmp/aveksa-install.log).
Before You Begin

The following procedure assumes that you extracted the installation files (from aveksa-<product
version>.tar.bz2) to the default location /tmp/aveksa/staging.
Procedure
1. Log in as root.
2. Respond yes or no to the prompt asking if you would like to install RSA Identity Governance and Lifecycle
as a service. If you select no, options related to services are not available.
3. Change to the location of the installation files. For example:
cd /tmp/aveksa/staging
4. Run the installation script. Enter
./install.sh
Note: By default, the installation script includes packages for Access Fulfillment Express module (AFX),
and the AFX menu is displayed in the user interface. AFX is not activated unless your license grants you
permissions to download and start the AFX server. For licensing, contact your RSA representative.
5. Press the space bar to scroll through the license text.

6. When prompted, enter yes to accept the terms of the license.
7. Specify the location for the installation. This is the directory where RSA Identity Governance and
Lifecycle will be installed.
8. Specify the location of the package files. If the suggested directory is correct, press Enter.
9. When prompted, enter N if you want to install RSA Identity Governance and Lifecycle with an RSA-
provided database, or Y to install a customer-supplied Oracle database.
If you entered Y, you will be prompted to provide information to identify your Oracle database. See Plan
the Customer-Supplied Database Configuration on page 16 for a list of the parameters (such as Oracle
listener hostname, port, SID, database users) that you need to input.
Note: If you created the database instance with non-default names for the database users, you must
use the same user names and passwords when prompted.
The installation begins. A summary displays the location of the package files, and information about the
Oracle database configuration.
10. If the summary of install information is correct for your system, enter "yes" at the following prompt:
Does this match your current install information (yes or no)?
11. If the summary of install information is incorrect, enter "no." The installation prompts you to provide the
correct information for each item.
The version number and build number are displayed.

12. If you want to install the version shown on the screen, enter yes.
13. Log out of all open sessions from the logged in account after the installation has finished. You need to log
in again to apply the environment changes to your session.
For information about actions performed during the installation, see the install log (/tmp/aveksa-install.log).
Perform Installation as the Oracle User

The installation script performs checks for the following installation requirements:
l Memory
l Disk space for partitions
l Operating system packages
l Network settings
l User and group settings
l System configurations
The script displays information about the checks, and it indicates if a requirement is not met. After you resolve
the requirement, you can run the script again.
Installation scripts and any installation errors are recorded in the install log (/tmp/aveksa-install.log).
Before You Begin

The following procedure assumes that you extracted the installation files (from aveksa-<product
version>.tar.bz2) to the default location /tmp/aveksa/staging.
Procedure
1. Log in to the application server as the root user.
2. Ensure that the user "oracle" exists and has the primary group assigned to "oinstall".
3. Run the following command:
chown -R oracle:oinstall /tmp/aveksa/staging
cd $STAGING_DIR/deploy/JDK-scripts
./installJDK.sh
5. Log in to the application server as the oracle user.

6. To install the application in a non-service mode, run one of the following commands as the oracle user:
l For a deployment without AFX, run install.sh.
l For a deployment with AFX, run install.sh -afx.
RSA Identity Governance and Lifecycle and AFX are installed in a non-service mode, and aveksa_server
and afx_server will not run as a service. They must be run from "$AVEKSA_HOME"/deploy/init.d/.
7. Log out of all open sessions after the installation has finished. You need to log in again to apply the
environment changes to your session.
For information about actions performed during the installation, see the install log (/tmp/aveksa-install.log).

Open Ports On the Firewall
On a Software Bundle, you need to open TCP ports on the firewall to allow communications with RSA Identity
Governance and Lifecycle.
To configure the firewall, see the section for your operating system:
l Firewall Configuration for Red Hat

l Firewall Configuration for SuSE
After you complete the installation, you can log on to RSA Identity Governance and Lifecycle from any compatible
Web browser.
Procedure
1. On the appliance, open a browser and enter the following URL:
https://<Fully Qualifed Domain Name (FQDN) or IP address>
2. Enter AveksaAdmin in the User Name box.
AveksaAdmin is the name of the administrator (superuser) in RSA Identity Governance and Lifecycle.
3. Enter aveksa123 in the Password box.

4. When prompted, enter a new password for this user in the New Password box.
This password must contain at least 8 characters, including one upper and one lower case character,
and one number.

6. Click OK.
Apply the Latest Database Patch Updates to a Software Bundle
Lifecycle appliance up-to-date with the latest patches. For a Software Bundle, RSA provides the Appliance
Updater, which bundles a certified patch set for an RSA-supplied Oracle database. Downloading and running
these patches closes vulnerabilities and bugs.
Note: The customer-supplied operating system should be updated regularly with patches supplied by the
vendor.
The patches are provided in a compressed file (rsaimg_updater_<release quarter>_<platform>.tar.bz2) and

posted to RSA Link at https://community.rsa.com/community/products/governance-and-lifecycle for

download.
Download and apply the appliance updater patches on a regular basis as updates are released.
is not available or you want to set a different directory, you must create the directory manually, and then specify
the location in a Java system variable.
Procedure
1. Log in to the system root.
2. If your system has an existing directory to store the encryption key, set its permissions to 700 (rwx-----
-) and make sure that the directory owner is the user under which RSA Identity Governance and
Lifecycle is running.
If a directory for storing the encryption key does not exist, RSA Identity Governance and Lifecycle
creates the directory. Ensure that the user running RSA Identity Governance and Lifecycle has write
permissions to the parent directory.
Note: In a clustered environment, each node must contain a directory for the encryption key.
<system-properties>
The default value for the directory is "/home/oracle/security" Change this if you use a
different directory to store the encryption key.
<system-properties>
Cluster <property name="rsavialg.security.keydir" value="/home/oracle/security"/>
directory where you will store your encryption key.

If the keys are lost, any data encrypted with those keys will be irrecoverable. We recommend that you
create a secure backup process for the keys and store the backup in a secure location.


Procedure



above).
Error Messages

KEK_ERROR_
directory.
WRITABLE
key directory.
KEK_ERROR_
ALREADY_ location.
/etc/hosts.
EXISTS
KEK_ERROR_
the directory.
WRITABLE
KEK_ERROR_ The encryption key storage directory Create the directory, set permissions to allow


DIRECTORY_ RSA Identity Governance and Lifecycle to
INVALID_
DIRECTORY_
PERMISSIONS
Configure Datasources
In a WildFly environment, you must update WildFly's datasources to properly detect database connectivity
issues. Perform the following procedure to enable the server to check the database connection every 30
seconds.
Procedure
1. Open the appropriate configuration file for your deployment type:
l Standalone: /home/oracle/wildfly/standalone/configuration/aveksa-standalone-full.xml
l Cluster: /home/oracle/wildfly/domain/configuration/domain.xml
2. For each <datasource>, add the following setting:
<validation>
<background-validation>true</background-validation>
<background-validation-millis>30000</background-validation-
millis>
<valid-connection-checker
class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.Oracle
ValidConnectionChecker"/>
<stale-connection-checker
StaleConnectionChecker"/>
<exception-sorter
class-name="com.aveksa.jdbc.OracleExceptionSorter"/>
</validation>



and Lifecycle

Procedure


<Keystore File>
For example:

-dname "CN=acm-
myCorpServer.
trusted.
Procedure

aveksa.keystore
acm restart

Procedure
1. Log in as root.

<Keystore File>
For example:

acm restart

store
Procedure

aveksa.keystore
where

aveksa.keystore
certificate.

acm restart
certificate.
and Lifecycle.


tab.
l Security


Chapter 5: Virtual Application Installation

Perform the following steps to install the virtual application.
1. Download and Install the RSA Identity Governance and Lifecycle Virtual Application OVA on page 53
2. Set Up the Database for the Virtual Application on page 54
3. Set Up the RSA Identity Governance and Lifecycle Virtual Application on page 54
4. Log on to RSA Identity Governance and Lifecycle on page 57
5. Apply the Latest Operating System and Database Patch Updates to a Virtual Application on page 58
6. Confirm the Setting for the Encryption Key Directory on page 58
7. Implement Security Best Practices on page 62
8. Setting Up User Access to RSA Identity Governance and Lifecycle on page 117
Download and Install the RSA Identity Governance and Lifecycle

Virtual Application OVA
RSA distributes the RSA Identity Governance and Lifecycle virtual application as an OVA file, which you
download and install as a virtual application. To deploy the virtual application, you must use VMware ESXi
version 5.x or higher.
Before You Begin

l Verify the software and database requirements described in Chapter 2, Review Installation
Prerequisites.
l You must have a valid license for RSA Identity Governance and Lifecycle.
Procedure
1. Go to RSA Link (https://community.rsa.com/community/products/governance-and-lifecycle), then click
Log In and enter your user name and password.
2. Click RSA Identity Governance and Lifecycle 7.2.1
3. Click Version Upgrades.
4. Click the Upgrade link for your licensed RSA Identity Governance and Lifecycle asset.
5. Click Continue.
6. On the Order Detail page, click the menu icon and select Product List.
The Current tab lists the most recent release or patch. The Archive tab lists previous releases and
patches.
7. Click the appropriate tab, and select the name of the release to download.
8. Download the OVA file:
RSA_IGL.x86_64-<VersionNumber>.ova
9. Follow the documentation for your virtual infrastructure to install the OVA, using the following

configuration settings:
Setting Value
CPU 4 CPUs, with 1 core per socket
Memory 16 GB or greater
Hard Disk Retain the default value
10. Power on the virtual application.
Set Up the Database for the Virtual Application
The virtual application requires a database that is installed on physical hardware. Before setting up the virtual
application, set up the database.
Before You Begin
l Verify Prerequisites for a Customer-Supplied Database on page 16.
l If you plan to deploy your own customer-supplied database, refer to the RSA Identity Governance and
Lifecycle Database Setup and Management Guide for requirements and instructions.
Procedure
1. Log into the database installation machine as root.
2. Extract the file RSA_IGL_DatabaseOnly.tar.bz2 to the /tmp directory using the following command:
tar xjf RSA_IGL_DatabaseOnly.tar.bz2
3. Execute the script installDatabaseOnly.sh using the following command:
./installDatabaseOnly.sh
When the script completes, a standalone Oracle database server is configured with the appropriate
tablespace, users, and schema for RSA Identity Governance and Lifecycle. Logs are accessible in the
/tmp/aveksa-install.log directory.
4. Log out of all open sessions from the root account after the installation has finished. You need to log in
again to apply the environment changes to your session.
Set Up the RSA Identity Governance and Lifecycle Virtual Application
Use the RSA Identity Governance and Lifecycle virtual application setup interface to configure the virtual
application. The setup interface automatically guides you through each step of the virtual application
configuration.
Use the arrow keys to move between form fields, and the Tab key to select options at the bottom of each screen.
54 Chapter 5: Virtual Application Installation

Before you begin
l Verify that the application server and database are configured to use the same region and time zone. To
determine and synchronize the time zone, do the following:
1. As the user sysdba, run the following query:
SELECT DBTIMEZONE FROM DUAL;
2. As the user avuser, run the following query:
SELECT avuser.Utilities_Pkg.Get_DBTimezone_Value FROM DUAL;
3. If the values from steps 1 and 2 are not identical, execute the following SQL statements:
alter database set time_zone='<value you got from the previous

second query>';
shutdown immediate;
startup;
Procedure
1. Power on the virtual machine and log in as root using the standard password.
2. At the prompt asking if you want to set up RSA Identity Governance and Lifecycle, use TAB to select Yes,
and press Enter.
3. Configure the network settings for the virtual application:
a. On the Main Menu screen, ensure that 1 Network Setup is selected, select OK, and press
Enter.
b. On the Network Configuration screen, enter the fully qualified domain name (FQDN), the IPv4 or
IPv6 IP Address, Netmask, and the default Gateway for your RSA Identity Governance and
Lifecycle deployment, then select Submit, and press Enter.
The network automatically restarts.
c. At the prompt asking if you want to verify the network, select Yes to verify your network
configuration or No to skip the test, and press Enter.
d. If you performed the network test, select OK after the test completes and press Enter.
4. Configure the domain name servers (DNS):

a. Ensure that 2 DNS Setup is selected, select OK, and press Enter.
b. Enter the IP addresses of your DNS, select Submit, and press Enter.
If DNS configuration is successful, a confirmation message appears.
c. Select OK and press Enter.
5. Configure the NTP server:

a. Ensure that 3 NTP Setup is selected, select OK, and press Enter.
b. Enter the IP address or hostname of your NTP server, select Submit, and press Enter.
A message is displayed indicating that it can take up to ten minutes to verify the NTP server

connection.
c. Select OK and press Enter.
6. Configure the Oracle database as follows. If you are migrating from an older OVA, provide the same
database details.
a. Ensure that 4 DB Setup is selected, select OK, and press Enter.
b. Enter the following details for your deployment, if applicable:
l Oracle Listening hostname
l Oracle Listener port
l Oracle SID
l Oracle Service Name
l Oracle Connection ID
l Aveksa (AveksaAdmin) user name
l Aveksa (AveksaAdmin) user password
l Reports user name
l Reports user password
l Public db user name
l Public db user password
l Statspack user name
l Statspack user password
c. Select Submit, and press Enter.

d. At the prompt asking if you want to verify the database connection, select Yes to verify that the
network and database are configured correctly, or No to return to the main menu, and press
Enter.
e. If you performed the database connection test, on the confirmation message, click OK, and press
Enter.
7. Configure RSA Identity Governance and Lifecycle on the virtual application:

a. Ensure that 5 Configure is selected, select OK, and press Enter.
b. At the prompt asking if you want to enable the Access Fulfillment Express (AFX) service, select
YES or NO, and press Enter.
The console displays details of the configuration as it is performed.
c. When the RSA Identity Governance and Lifecycle configuration is complete, press any key to
return to the main menu.
8. (Optional) To disable the setup interface from automatically running after logging into the virtual
application as root:
a. Select 6 Disable, select OK, and press Enter.
b. At the confirmation message, select Yes, and press Enter.
9. (Optional) To display the status of the virtual application configuration:

a. Select 7 Status, select OK, and press Enter.
The test progress is displayed as the network, NTP, and database connections are tested. When
the test is complete, the test results are displayed to indicate whether items are successfully

configured.
b. Select OK, and press Enter.
10. (Optional) To turn the color mode on or off for the status labels, Select 8 Turn on/off color mode,
select OK, and press Enter.
When color mode is enabled, the virtual application setup interface color-codes the status label for each
configuration step. When disabled, the status labels appear as standard text. This option can help with
status readability.
Manually Start the Virtual Application Setup Interface

You can manually start the virtual application setup interface if you disabled the option to automatically run at
login.
Procedure
2. Run the following script:
/usr/local/bin/run-setup
Configure the Virtual Application Setup Interface to Run Automatically

Configure the virtual application setup interface to run automatically at login, if you had previously disabled this
feature.
Procedure
2. Update /root/ .bash_profile by removing the # character from the following line:
#run-setup
3. Save your changes and log out of the virtual machine.
The virtual application setup interface will automatically run at the next login.
After you complete the installation, you can log on to RSA Identity Governance and Lifecycle from any compatible
Web browser.
Procedure
1. On the appliance, open a browser and enter the following URL:
https://<Fully Qualifed Domain Name (FQDN) or IP address>

2. Enter AveksaAdmin in the User Name box.
AveksaAdmin is the name of the administrator (superuser) in RSA Identity Governance and Lifecycle.
3. Enter aveksa123 in the Password box.

4. When prompted, enter a new password for this user in the New Password box.
This password must contain at least 8 characters, including one upper and one lower case character,
and one number.

6. Click OK.
Apply the Latest Operating System and Database Patch Updates to a

Virtual Application
Lifecycle deployment up-to-date with the latest patches. The virtual application OVA contains the most up-to-
date version of the operating system. To update the operating system and database for your virtual application,
you can either download a later version of the OVA, or use the Appliance Updater.
RSA provides the Appliance Updater to achieve that goal. It bundles a certified patch set for the operating
system of an RSA appliance and the database on the appliance. Downloading and running these patches closes
vulnerabilities and addresses bugs.
The patches are provided in a compressed file (rsaimg_updater_<release_date>_<platform>.tar.bz2) and

posted on RSA Link at https://community.rsa.com/community/products/governance-and-lifecycle.
Download and apply the appliance updater patches on a regular basis as new patches are released.
is not available or you want to set a different directory, you must create the directory, and then specify the
location in a Java system variable.
Procedure
1. Log in as root.

running.
l For a cluster, this same directory also needs to exist on each of the nodes.
<system-properties>
The default value for the directory is "/home/oracle/security" Change this to the directory
where you will store the encryption key.
<system-properties>
Cluster </system-properties>
directory where you will store the encryption key
ensure that the keys are not compromised during the backup or after they are in the backup location.



Procedure


above).
Error Messages


KEK_ERROR_
directory.
WRITABLE
key directory.
KEK_ERROR_
ALREADY_ location.
/etc/hosts.
EXISTS
KEK_ERROR_
the directory.
WRITABLE
DIRECTORY_ The encryption key storage directory RSA Identity Governance and Lifecycle to
INVALID_
DIRECTORY_
PERMISSIONS
Configure Datasources
In a WildFly environment, you must update WildFly's datasources to properly detect database connectivity
issues. Perform the following procedure to enable the server to check the database connection every 30
seconds.

Procedure
1. Open the appropriate configuration file for your deployment type:
l Standalone: /home/oracle/wildfly/standalone/configuration/aveksa-standalone-full.xml
l Cluster: /home/oracle/wildfly/domain/configuration/domain.xml
2. For each <datasource>, add the following setting:
<validation>
<background-validation>true</background-validation>
<background-validation-millis>30000</background-validation-
millis>
<valid-connection-checker
ValidConnectionChecker"/>
<stale-connection-checker
StaleConnectionChecker"/>
<exception-sorter
class-name="com.aveksa.jdbc.OracleExceptionSorter"/>
</validation>


and Lifecycle


Procedure

<Keystore File>
For example:

-dname "CN=acm-
myCorpServer.

trusted.
Procedure

aveksa.keystore
acm restart

Procedure
1. Log in as root.

<Keystore File>
For example:

acm restart
store
Procedure

aveksa.keystore
where


aveksa.keystore
certificate.

acm restart
certificate.
and Lifecycle.

tab.
l Security



Chapter 6: WebSphere Installation

Perform the following tasks to install the RSA Identity Governance and Lifecycle on a standalone WebSphere
server or in a clustered server environment.
1. Download Installation Files For WebSphere

2. Configure RSA Identity Governance and Lifecycle Resources on WebSphere
3. Configure a Non-SSL Port for WebSphere
4. Install RSA Identity Governance and Lifecycle Using the Aveksa EAR File
5. Install the Workflow Architect EAR File
6. Configure the RSA Identity Governance and Lifecycle Shared Library
7. Confirm the Setting for the Encryption Key Directory
8. Configure SSL for Internal Communication Between RSA Identity Governance and Lifecycle Components
9. Configure SSL for External Communication (Browser or Web Services to RSA Identity Governance and
Lifecycle)
Before You Begin
l Verify that your machine meets the prerequisites for hardware, software, and database described in
Chapter 2, Installation Prerequisites.
l Personnel performing the installation should be a trained System Administrator in WebSphere
Application Server Network Deployment.
l Determine if you need to use a modified version of RSA Identity Governance and Lifecycle. See If You
Need a Modified Version of RSA Identity Governance and Lifecycle.
l Confirm that a cluster is already configured for an RSA Identity Governance and Lifecycle deployment.
You need information about each application server instance in the cluster. For background information
about running RSA Identity Governance and Lifecycle in a cluster, see Clustered Application Server and
Oracle RAC Implementation Environments.
If You Need a Modified Version of RSA Identity Governance and Lifecycle

You might be required to modify RSA Identity Governance and Lifecycle under the following circumstances:
l You use non-default named database user schemas.

l You use non-default database tablespace names.
l To support integration with third-party provisioning systems.
l To implement other custom functionality.
For more information, see:
l Modifying the Enterprise Archive for information on setting up a customization directory where you can
configure custom RSA Identity Governance and Lifecycle settings for WebSphere.
l Setting Up RSA Identity Governance and Lifecycle > Integrations in Help for customizing settings for
integration with any of the following:

l Novell Identity Manager

l Sun Identity Manager
l IBM Tivoli Identity Manager
Clustered Application Server and Oracle RAC Implementation Envir-

onments
The following illustration depicts RSA Identity Governance and Lifecycle deployment in a clustered application
server environment, and implementing an Oracle Real Application Cluster (RAC).
RSA Identity Governance and Lifecycle in a Clustered Application Server Environment

You can install RSA Identity Governance and Lifecycle on multiple application server instances in a cluster. Each
70 Chapter 6: WebSphere Installation

instance running RSA Identity Governance and Lifecycle is called a node. The application server administers the
nodes collectively as a cluster that shares a common database to provide a scalable environment. Nodes self-
register with the database on startup.
Each node can support up to 250 client sessions. There are two types of nodes:
l A single System Operations Node (SON), which handles operations, such as data collections, agent
management, review generation, and policy processing.
l One or more general nodes, which handles user interface processing.
For more information, see the Help topic, "Managing Server Cluster Nodes."
Oracle RAC for an RSA Identity Governance and Lifecycle Deployment

An Oracle Real Application Cluster (RAC) database has more components and more complexity than a single-
instance Oracle database. Familiarize yourself with these components so you can make appropriate decisions for
your environment.
The following describe each RAC component and recommendations for RSA Identity Governance and Lifecycle:
l Oracle RAC Database Instances — An Oracle RAC installation typically includes two or more database
instances, each with its own memory and local working cache. Each node requires two network
interfaces to communicate with both application servers on the public network and private network that
is used for both shared storage and the cluster .
RSA recommends that each database node has a local hard disk that holds the individual Oracle
clusterware and Oracle database homes in addition to the operating system and local swap files.
l Private Network — The private network used for coordinating cluster activities and the network that
accesses the shared storage system. The private network allows the Oracle cluster to the access Cluster
Ready Services (CRS)/Voting disk. Because RSA Identity Governance and Lifecycle operates in a mixed
Online Transaction Processing (OLTP) and Decision Support System (DSS) mode, many installations
benefit from a faster 10-Gbit network to support the caching requirements of DSS operations such as
collections and report generation.
l Shared Storage — RSA Identity Governance and Lifecycle supports Storage Area Network (SAN) systems
with multiple disk volumes. SANs with RAID 5 or RAID0+1 provide the required read-write performance
for the Oracle RAC.
The shared storage system, along with Oracle Automatic Storage Management (ASM), provides three
types of storage for the cluster that will be assigned to Logical Unit Numbers (LUN). Traditional Oracle
tablespace storage will occupy most of the space and will be stored in the LUN "VOL1." A second LUN,
will be created for cluster activities and will be assigned to the LUN "CRS1."
The third LUN will provide a general purpose "cluster-aware" file system that will be shared with all of
the members of the cluster and will be assigned to the LUN "FS1." Oracle requires this "cluster-aware"
file system be used when setting up Oracle directories in a cluster. Because RSA Identity Governance
and Lifecycle requires the AVEKSA_EXPORTIMPORT_DIRECTORY, we recommend a configuration that
uses Oracle Automatic Storage Management Cluster File System (Oracle ACFS) to create a mountable
volume usable by the operating system itself.

Download Installation Files for WebSphere
Before You Begin

To download the necessary files, you must have a valid license for RSA Identity Governance and Lifecycle7.2.1.
Procedure
1. Log on to the machine hosting the WebSphere application server.
2. Choose a download directory.
3. Download the installation files:
f. Click Continue.

l ACM-WebSphere-<product version>.tar
4. Expand the tar file:
cd /opt
tar xvf ACM-WebSphere-<product version>.tar
This command creates an ACM-WebSphere directory containing all required software components. The
directory location is referred to as DISTRIBUTION in this chapter.
Configure RSA Identity Governance and Lifecycle Resources on

WebSphere
Use the WebSphere console to perform all installation and configuration steps. See your WebSphere
administrator for the URL and access credentials. All values are expected to be set to the default values, unless
otherwise specified.
Application server resources must be created with the correct scope, which differs between distributed
application servers (clustered) and a standalone server. When configuring for a clustered environment, you
might need to synchronize or restart nodes. See the Database Configuration Values for more information.
Configure Application Server Memory

RSA Identity Governance and Lifecycle has minimum JVM memory requirements. Ensure that the settings are
adequate for each managed server on which it is deployed, standalone or cluster. In a clustered environment,

you must increase the memory on the deployment manager used to deploy to the nodes. The default memory for
the deployment manager (dmgr) is insufficient for this task.
Also ensure your hardware has sufficient physical memory for those requirements. Use this procedure to
modify the following JVM memory parameters for RSA Identity Governance and Lifecycle:
l Maximum JVM heap Size. 8 GB is the minimum requirement for a production environment. Additional
memory may be required based on the size of the data and the number of concurrent users. For
example, 32 GB is expected to support up to 300 concurrent users.
The JVM argument is –Xmx. For example (8 GB): –Xmx8192m. Set the memory based on your deployment
requirements.
Note: JDK 1.7 additionally requires a maximum permanent generation heap size of at least 512 MB: –
XX:MaxPermSize=512m
This command is deprecated in JDK 1.8.
Before You Begin

l Ensure that the settings are adequate for each standalone or distributed application server on which it is
deployed.
l Ensure your hardware has sufficient physical memory for those requirements.
Procedure
1. In the WebSphere console, to select the server, click Servers > Server types > WebSphere application
servers > Select server.
2. Choose the server used for RSA Identity Governance and Lifecycle.
3. Under the Configuration tab, select Server Infrastructure > Java and Process Management > Process
Definition.
4. Under Additional Properties, select Java Virtual Machine.
5. Set the following maximum heap value (or greater as necessary):
Maximum Heap (8 GB example): 8192
6. Save to the master configuration.
Configure JVM Settings
Use the WebSphere console to configure the appropriate JVM settings for your deployment.
Note: RSA Identity Governance and Lifecycle requires UTF-8 character encoding . Ensure that the JVM settings
are set to UTF-8 for each standalone or clustered server on which it is deployed..
Procedure
1. In the WebSphere console, to select the server, click Servers > Server types > WebSphere
application servers > Select server.
3. Under the Configuration tab, select Server Infrastructure > Java and Process Management >
Process Definition.
4. Under Additional Properties, select Java Virtual Machine.

5. Under Generic JVM Arguments, perform the following steps:

a. Enter the following to set the character encoding:
-Dclient.encoding.override=UTF-8 -Dfile.encoding=UTF-8
b. Add the following setting to specify the protocol, such as http or https, that your deployment
uses:
-Dwp-client-protocol=<protocol>
c. In deployments that use a load balancer, such as a clustered environment, add the following
setting:
-Dwp-client-hostname=<hostname>
d. If your deployment does not use the default port setting for HTTP, add the following setting:
-Dwp-client-hostport=<hostport>
Note: Use only one space between arguments in the JVM arguments field. For example:
–XX:MaxPermSize=512m -Dclient.encoding.override=UTF-8 -Dfile.encoding=UTF-8
Create Authentication Users

When you set up the Oracle database for RSA Identity Governance and Lifecycle, you created the following
database users. You must create entries for these same users in WebSphere:
l RSA Identity Governance and Lifecycle user. The default name is AVUSER.
l RSA Identity Governance and Lifecycle reporting engine user. The default name is AVDWUSER.
l RSA Identity Governance and Lifecycle public database schema user. The default name is ACMDB.
l RSA Identity Governance and Lifecycle Statistics Report user. The default name is AVPERF. This user is
required only if Oracle Statspack is installed on the database and you want to include Statspack data in
RSA Identity Governance and Lifecycle Statistics Reports. If you do not have the statspack on your
database do not create the avperf objects — user and data source. However, you must enter a value in
the resource mapping during deployment. See the Database Setup and Management Guide for
information on Statspack installation.
Note: If you created your database instance with non-default names, you must use the same user names and
passwords when you create the authentication users and aliases.
Before You Begin

Make sure you have the user name and password for the database users listed above.
Procedure
1. In the WebSphere console, from the Security menu, select Global Security.
2. Under Authentication, expand Java Authentication and Authorization Service and select J2C
authentication data.

3. Click New to create each database user.

l AVUSER
l Alias: avuser
l User ID: <avuser>
l Password: <avuser password>
l Description: ACM avuser
l AVDWUSER
l Alias: avdwuser
l User ID: <avdwuser>
l Password: <avdwuser password>
l Description: ACM avdwuser
l ACMDB
l Alias: acmdb
l User ID: <acmdb>
l Password: <acmdb password>
l Description: ACM acmdb
l AVPERF
l Alias: avperf
l User ID: <perfstat>
l Password: <perfstat password>
l Description: Statspack user
4. Save changes to the master configuration.
Create the ACM Oracle JDBC Provider

A JDBC provider enables RSA Identity Governance and Lifecycle to access data sources. Use the JDBC drivers
provided in the ACM-WebSphere.tar file.
Procedure
1. In the WebSphere console, from the Resources menu, select JDBC > JDBC Providers.
2. Set the scope:
l (Standalone) Node=<machine-name>Node01, server=server1)
l (Cluster) cluster=MyCluster
3. Click New to create the JDBC Provider:

l Database type: Oracle
l Provider type: Oracle JDBC Driver
l Implementation type: Connection pool data source
l Name: ACM Oracle JDBC Driver
4. Click Next to enter database classpath information.

5. In the Class Path section, enter the following three lines, separated by the ENTER key:
${ORACLE_JDBC_DRIVER_PATH}/ojdbc8-12.2.0.1.0.jar
${ORACLE_JDBC_DRIVER_PATH}/xdb6-12.2.0.1.0.jar

${ORACLE_JDBC_DRIVER_PATH}/xmlparserv2_sans_jaxp_services-
12.2.0.1.0.jar
6. In the Directory location forojdbc8-12.2.0.1.0.jar section, enter the location of the following JDBC jar
files: ojdbc8-12.2.0.1.0.jar, xdb6-12.2.0.1.0.jar,xmlparserv2_sans_jaxp_services-12.2.0.1.0.jar.
8. (Clusters only) Restart the server and node agents after configuration of the JDBC Provider and before
the creation of the JDBC data sources.
Create the JDBC Data Sources

You must create the JDBC data sources RSA Identity Governance and Lifecycle uses to access the database.
The following default RSA Identity Governance and Lifecycle database user schema names are used in this task:
RSA Identity Governance and Lifecycle Statistics Reports. Statspack can provide useful runtime
diagnostic information. See the Database Setup and Management Guide for information on Statspack
installation. The data source is optional, but you must enter a value in the resource mapping during
deployment.
Note: If you created the database instance with non-default names, you must use the same user names and
passwords when you create the JDBC data sources. See the Database Setup and Management Guide to ensure
that the database instance meets RSA Identity Governance and Lifecycle product requirements. To configure the
JDBC data sources, you need the Oracle SID, Oracle listener hosts, Oracle listener port, and Oracle service
name.
This task describes how to create the following required JDBC data sources:
l avdb
l avdwdb
l acmdb
l avperf — Required only if Oracle Statspack is installed on the database and you want to include
Statspack data in RSA Identity Governance and Lifecycle Statistics Reports. This optional data source
provides valuable runtime diagnostic information.)
Test each data source after you create it to validate the connection configuration.
Procedure
1. In the WebSphere console, from the Resources menu, select JDBC > Data Sources.
2. Set the scope:
l (Standalone) Node=<machine-name>Node01, server=server1)

3. Click New to create each data source:

l AVDB data source
l Data source name: avdb
l JNDI name: jdbc/avdb
l Select an existing JDBC Provider: ACM Oracle JDBC Driver
l URL: jdbc:oracle:thin:@<oracle-listener-host>:<oracle-listener-port>/<oracle-service-name>
For example: jdbc:oracle:thin:@my_oracle_host:1555/avdb
l Data store helper class name: Oracle 10g or Oracle 11g (whichever is used for RSA
Identity Governance and Lifecycle)
l Component-managed authentication alias: avuser
l AVDWDB data source

l Data source name: avdwdb
l JNDI name: jdbc/avdwdb
l JDBC Provider: ACM Oracle JDBC Driver
l Data store helper class name: Oracle 10g, Oracle 11g, or Oracle 12c (whichever is used
for RSA Identity Governance and Lifecycle)
l Component-managed authentication alias: avdwuser
l Non-transactional data source: Yes
l ACMDB data source

l Data source name: acmdb
l JNDI name: jdbc/acmdb
l Component-managed authentication alias: acmdb
l AVPERF data source

l Name: avperf
l JNDI name = jdbc/avperf
l Component-managed authentication alias: avperf
l URL: jdbc:oracle:thin:@<oracle-listener-host>:<oracle-listener-port>/<oracle-service-
name>

4. Edit each data source configuration and save changes to the master configuration after each edit:
l For all data sources:
a. Select Resources > JDBC > Data Sources > data source.
b. Select WebSphere Application Server Data Source properties under Additional Properties.
c. Go to the Connection Validation Properties section.
d. Select Validate new connections.
e. Select Validate existing pooled connections.
f. Click Validation by JDBC Driver.
g. Set Timeout: 30 seconds.
h. Save the changes for all data sources.
l For the avdb data source:

l Under Additional Properties > Connection pool properties, set Maximum connections to
300.
l For the avdwdb, acmdb, and avperf data sources:

l Under Additional Properties > Connection pool properties, set Maximum connections to
50.
l Restart the application server after saving changes to the data sources.
5. From the Data source page, test the connections to the data sources by selecting each data source and
click Test Connection.
Configure the WebSphere Bus and Bus Destinations

Note: This topic provides an example using a single node cluster with two cluster members configured for
scalability. Please consult your WebSphere vendor for configuration recommendations that are appropriate for
your requirements.
You must define wpUtilQueue for the RSA Identity Governance and Lifecycle workflow engine. The workflow
engine handles the processing of access requests.
Procedure
1. In the WebSphere console, from the Service integration menu, select Buses.
2. Click New and create the wpBus bus:
Name: wpBus
Make sure the Bus security checkbox is deselected.
3. Under Buses, click wpBus to display the configuration.

4. Under Topology, select Bus Members.
5. Click Add and create a new member:
l (Standalone server) Select Server, then select the associated server from the drop-down list.
l (Cluster) Select Cluster.

Note: In a cluster, the next page prompts to select the Messaging Engine policy assistance
settings. Please consult your WebSphere vendor for recommendations. The most commonly used
setting is "Scalability."
Note: The Bus Member is associated with a message store that is required. By default this is a
file store within the WebSphere installation.
Note: In a cluster, all servers must access the message store for the messaging engine. This is
more easily done using a data store configuration, but can be done using a file store if all servers
can access the file location.
l Message store: Select File Store or Data Store. Configure the store for your environment:
l File store requires directory path information for logging to the file system.
l Data store requires information for data access. You need to provide the pre-configured
data-source JNDI name and authentication alias.
6. Select wpBus to return to the configuration page.

7. Under Destination resources, select Destinations.
8. Click New to configure the destination:
l Destination type: Queue
l Identifier: wpUtilQueue
l Bus member: The member that will process this queue. In a standalone environment, this is the
server. In a cluster, this is the cluster.
9. Select wpBus to return to the configuration page.

10. Under Destination resources, select Destinations.
11. Click New and create the acmMessageTopic destination:
l Destination type: Topic Space
l Identifier: acmMessageTopic
Configure a JMS Provider

You must configure a JMS provider.
Procedure
1. In the WebSphere console, from the Resources menu, select JMS > JMS Provider.
2. Set the scope:
l (Standalone) Node=<machine-name>Node01, server=server1
3. Choose Default messaging provider.
4. Under Additional properties, click Queues.
5. Click New to create the JMS queue:
l Name: wpUtilQueue
l JNDI name: queue/wpUtilQueue

l Bus name: wpBus
l Queue name: wpUtilQueue
6. Select Default messaging provider to return to the configuration page.

7. Under Additional properties, click Activation specifications.
8. Click New to create the activation specification:
l Name: wpUtilActSpec
l JNDI name: jms/wpUtilActSpec
l Destination type: queue
l Destination JNDI name: queue/wpUtilQueue
l Bus Name: wpBus
l Authentication alias: avuser
9. Under Additional properties, click Topic connection factories.

10. Click New to create the acmConnectionFactory connection factory
l Name: acmConnectionFactory
l JNDI name: jms/acmConnectionFactory
l Bus Name: wpBus
l (WebSphere 8.5.5.x only) Container-managed authentication alias: avuser
l (WebSphere 9.0.0.x only) Authentication alias for XA recovery: avuser

12. Under Additional properties, click Topics.
13. Click New to create the acmMessageTopic topic
l Name: acmMessageTopic
l JNDI name: topic/acmMessageTopic
l Bus Name: wpBus
l Topic space: acmMessageTopic

15. Under Additional properties, click Activation specifications.
16. Click New to create the acmSubscriberActSpec activation specification
l Name: acmSubscriberActSpec
l JNDI name: jms/acmSubscriberActSpec
l Destination type: topic
l (WebSphere 9.0.0.x only) Connection factory lookup: jms/acmConnectionFactory
l Destination JNDI name: topic/acmMessageTopic
l Bus Name: wpBus
l Authentication alias: avuser
l (WebSphere 9.0.0.x only) Subscription name: acmMessageCluster
l (WebSphere 9.0.0.x only) Ensure that "Always activate MDBs in all servers" is selected.

18. Restart the WebSphere server to initialize the JMS objects before deployment.

Install RSA Identity Governance and Lifecycle Using the Aveksa EAR
File
This section describes how to install the RSA Identity Governance and Lifecycle application by using the Aveksa
EAR File.
Before you begin
In a clustered environment, consider the following:
l Identify which node is the system operations node (SON). By default, the initial server instance is the
system operations node (SON) on any newly created cluster.
l Installation requires a single connection to the database for setup and migration. Use a single node and
make sure only one server instance is running. While this can be any node, RSA recommends using the
SON node for the installation or upgrade process.
l If migrating or patching a clustered deployment, you are required to run the SON without any other
active nodes before using the system. The SON must be started after installation is complete to properly
instantiate any workflow updates and ensure that any new RSA Identity Governance and Lifecycle
security model changes are initialized.
Procedure
1. In the WebSphere console, initiate the installation:
a. From Applications menu, select Application Types > websphere enterprise applications, and
click Install.
b. Browse to the aveksa.ear file in the DISTRIBUTION folder or in the customization directory
(specified in Modifying the RSA Identity Governance and Lifecycle Enterprise Archive on page
188) as required.
2. Proceed through the wizard, choosing the Fast Path.
Accept default values where not indicated otherwise.
3. (Clusters only) Select Map Modules to Servers. Select all modules, select the scope from the list of
Clusters and Servers, and click Apply. The server associated with the module should be listed as the
cluster. Click Next.
4. Select "Prompt me only when additional information is required," and click Next.
5. Select Bind listeners for message-driven beans and activation specification for each EJB module. Set the
Target Resource JNDI Name as follows:
l SubscriberMDB: jms/acmSubscriberActSpec
l (WebSphere 9.0.0.x only) Destination JNDI name:
topic/acmMessageTopic
6. Select Map resource references to resources. Most of the Target Resource JNDI Names are defined by
default. You must configure six additional resources: two resources for the subscriber Message bean
(SubscriberMDB) and four JDBC resources for the Aveksa application. Enter the following values:

l For the SubscriberMDB resource reference, browse to or enter jms/acmConnectionFactory.
l In the DataSource section, configure DataSource Target Resource JNDI name for the
SubscriberMDB EJB. For jdbc/avdb, browse avdb to or enter jdbc/avdb.
At the bottom of the page, configure DataSource Target Resource JNDI names for the Aveksa application.
l For jdbc/avdb, browse to avdb or enter jdbc/avdb.
l For jdbc/avdwdb, browse to avdwdb or enter jdbc/avdwdb.
l For jdbc/acmdb, browse to acmdb or enter jdbc/acmdb.
l For jdbc/avperf, browse to avperf or enter jdbc/avperf, regardless of whether Statspack is

configured for the database. Even if an avperf datsource is not created, you must enter the value
for the installation to complete.
7. Map the resource environment references to the resources section.
To map topic/acmMessageTopic to the resource, in the Target Resource JNDI field, enter
topic/acmMessageTopic.
8. In the Map Virtual Hosts for Web Modules screen, click Next.

9. In the Metadata for modules screen, click Next.
10. Complete the installation of the EAR. This process takes several minutes to complete.
12. Start the RSA Identity Governance and Lifecycle application. You typically use the WebSphere console to
start and stop the application. In a cluster, be sure to only start the application on a single node.
Because the entire database schema for RSA Identity Governance and Lifecycle must be created during
the initial post-installation restart, the process might take several minutes.
You can view the SystemOut.log file to check the restart progress. The file is located in the path similar
to: $WEBSPHERE_HOME/AppServer/profiles/AppSrv01/logs/server1. See Troubleshooting a
WebSphere Installation on page 145 for more information on log files.
13. Verify your installation by accessing RSA Identity Governance and Lifecycle through your WebSphere
server port at: http://<server or node name>:9080/aveksa/main.
Note: Port 9080 is the standard WebSphere server port, but your deployment might use a different
port.
In a cluster, verify your installation before starting additional nodes.
Once the SON node is started and validated, all other nodes can be started. For information on how to
manage RSA Identity Governance and Lifecycle instance nodes in the cluster, see the Help topic,
"Managing Server Cluster Nodes."
Install the Workflow Architect EAR File
This task describes how to install the RSA Identity Governance and Lifecycle Workflow Architect. You use the
Workflow Architect to view and edit workflows for change requests.

During the deployment process, a cluster requires a single connection to the database for setup and migration.
Make sure you use a single node during the process and that only one server instance is running.
Procedure
1. In the WebSphere console, Initiate the installation:
a. From Applications menu, select Application Types > Websphere Enterprise Applications, and
click Install.
b. Browse to the aveksaWFArchitect.ear file in the DISTRIBUTION folder.
2. Proceed through the wizard, choosing the Fast Path.
Accept default values where not indicated otherwise.
3. (Clusters only) Select Map Modules to Servers. Select all modules, select the scope from the list of
Clusters and Servers, and click Apply. The server associated with the module should be listed as the
cluster. Click Next.
4. In the Map Virtual Hosts for Web Modules screen, click Next.
5. (WebSphere 9.0.0.x only) In the Metadata for modules screen, enable the metadata-complete attribute
checkbox and click Next.
6. Complete the installation of the EAR. This process takes several minutes to complete.
Configure the RSA Identity Governance and Lifecycle Shared Library
This step is required as part of the WebSphere installation process.
Before you begin
Deploy the Aveksa EAR. See Install RSA Identity Governance and Lifecycle Using the Aveksa EAR File.
To configure the shared library:

1. From the WebSphere admin console, go to Environment > Shared libraries.
2. Set the scope for your configuration:
l (Standalone) Node=<machine-name>Node01, server=server1
l (Cluster) cells=MyCluster
3. Click New to create the shared library:

l Name: Aveksa Shared Library
l Classpath: Full path to hibernate-jpa-2.0-api-1.0.1.Final.jar and javassist-3.18.1-GA.jar and
jakarta.mail-1.6.5.jar that is included in the DISTRIBUTION directory. For example, if your
DISTRIBUTION directory is /opt/ACM-WebSphere-<product version> then the full path would be
/opt/ACM-WebSphere-<product version>/ hibernate-jpa-2.0-api-1.0.1.Final.jar, /opt/ACM-
WebSphere-<product version>/javassist-3.18.1-GA.jar and /opt/ACM-WebSphere-
<productversion>/jakarta.mail-1.6.5.jar.
4. Under the Class Loading section, select Use an isolated class loader for this shared library.
To associate the Aveksa Shared Library with the Aveksa EAR:

1. From the WebSphere admin console, go to Applications > Application Types > WebSphere enterprise
applications.
2. Select the aveksa application on the Enterprise Applications page.
3. Under the References section, click the Shared library references link.
4. Select the aveksa application, and then click Reference shared libraries.
5. On the Shared Library Mapping page, select Aveksa Shared Library from the Available list and move it to
the Selected list.
6. Click OK to save changes.
The Key Encryption Key (KEK) is the key used to encrypt all other encryption keys. The installation (or upgrade)
creates a unique KEK and stores it in the encryption key directory. The default location of the directory is
/home/oracle/security. If the default directory is not available or you want to set a different directory, you must
create the directory, and then specify the location in a Java system variable.
Procedure
1. Log in to the system as root.
running.
3. Set a Java system property "rsavialg.security.keydir" to the directory where the encryption key is stored.
Perform these steps in the Admin console for WebSphere:
1. To select the server, click Servers > Server types > WebSphere application servers > Select
server.
Process Definition.
4. Under Additional Properties, select Java Virtual Machine > Custom Properties.
5. Select New, then enter:
Name: rsavialg.security.keydir
Value: <directory path for encryption key>
For example, in a standalone environment:
rsavialg.security.keydir=<directory path for the encryption key>

For example, in a cluster environment:
rsavialg.security.keydir=<server and directory path for the encryption key>, where

server is the hostname of a common network path that is accessible from all nodes.(You could
also set this up on each node by defining a local directory path on each node.)
4. Create a secure backup process to back up the keys that are in the encryption key directory. RSA Identity
ensure that the keys are not compromised, or otherwise exposed, during the backup or after they are in
the backup location.


Procedure
1. In the Admin console, add a java system property named "rsavialg.security.strict.permissions.disabled"
property and set the value to "true" as shown for the platform type:
1. To select the server, click Servers > Server types > WebSphere application servers > Select
server.
Process Definition.
4. Under Additional Properties, select Java Virtual Machine > Custom Properties.
5. Select New, then enter:
Name: rsavialg.security.strict.permissions.disabled
Value: true
If the directory already exists, set its permissions such that the user (owner of the process under which
RSA Identity Governance and Lifecycle is running) has “rwx” access into this directory. The owner of the
directory need not be the same as the owner of the application process, but the owner of the application
process must be able to read and write into this directory. This means “rwx” permissions have to be set
for the appropriate file permission field (owner, group, all) , which will allow the application process full
access.
If the directory does not exist, it is recommended that you create it. Set up the permissions on the
directory as specified in the previous item.

If the directory does not exist and you do not create it, the application will attempt to create the directory
on first startup using default permissions and the directory will be owned by the same user as the
application process.


above).
Error Messages
The following table contains a list of error messages that might display (in the AveksaServer.log) after you
configure the encryption key directory. The table lists default directory paths for the encryption key directory

Create the directory structure, set
KEK_ERROR_
The parent directory /home/oracle for the permissions to allow RSA Identity
PARENT_
specified encryption key storage directory Governance and Lifecycle to read from
DIRECTORY_DOES_
/home/oracle/security does not exist. and write to the directory, and specify
NOT_EXIST
the encryption key directory again.
KEK_ERROR_ Change permissions on the specified
The parent directory /home/oracle for the
PARENT_ encryption key directory to allow RSA
DIRECTORY_IS_NOT_ Identity Governance and Lifecycle to
/home/oracle/security is not writable.
WRITABLE write to the directory.
The parent /etc/hosts for the specified
KEK_ERROR_ Specify a directory path for the
encryption key storage directory
PARENT_IS_A_FILE encryption key directory.
/etc/hosts/security is a file, not a directory.
KEK_ERROR_FILE_ Specify a directory location, not a file
ALREADY_EXISTS location.
/etc/hosts.
Create the directory, set permissions to
KEK_ERROR_COULD_ allow RSA Identity Governance and
Could not create the encryption key storage
NOT_CREATE_ Lifecycle to read from and write to the
directory /home/oracle.
DIRECTORY directory, and specify the encryption
key directory again.
KEK_ERROR_ Verify that directory permissions are set
The encryption key storage directory
DIRECTORY_IS_NOT_ to allow RSA Identity Governance and
/home/oracle is not writable.
WRITABLE Lifecycle to write to the directory.
Create the directory, set permissions to
KEK_ERROR_ allow RSA Identity Governance and
DIRECTORY_DOES_ Lifecycle to read from and write to the
/home/oracle does not exist.
NOT_EXIST directory, and specify the encryption
KEK_ERROR_ The encryption key storage directory Verify that directory permissions are set


to allow RSA Identity Governance and
Lifecycle to write to the directory.
INVALID_ Alternatively, you can set a system
permissions. Please refer to the installation
DIRECTORY_ property to remove this restriction. See
documentation for a system property that can
PERMISSIONS "Using Non-restrictive Mode for the
be set to remove this restriction.
Encryption Key Directory" in the
previous section.
Configure SSL for Internal Communication Between RSA Identity

Governance and Lifecycle Components
AFX servers and remote agents use an self-signed certificate when communicating with the RSA Identity
Governance and Lifecycle server over an Secure Sockets Layer (SSL) connection. This self-signed certificate
and the RSA Identity Governance and Lifecycle server certificate signed by the Certificate Authority (CA) reside
in the RSA Identity Governance and Lifecycle keystore file server.keystore. This server.keystore file is used as a
keystore and truststore as it contains RSA Identity Governance and Lifecycle server certificates and the chained
trusted certificate of the RSA Identity Governance and Lifecycle CA. RSA Identity Governance and Lifecycle
trusts connections with AFX servers and remote agents because their certificates have been signed by the RSA
Identity Governance and Lifecycle CA.
To enable SSL communications between RSA Identity Governance and Lifecycle and AFX or agents, you must
make the server.keystore available to WebSphere by completing the following high-level tasks:
Procedure
1. Download the server.keystore file from RSA Identity Governance and Lifecycle to the WebSphere server.
2. Create a keystore in WebSphere using the downloaded server.keystore.
3. Configure SSL in WebSphere using the server.keystore.
4. Configure the SSL port.
The following sections describe how to perform the tasks.
Note: If an agent is installed on a remote machine, you must configure the agent and RSA Identity Governance
and Lifecycle to use SSL for communication. You must edit the agent’s configuration file to change the hostname
from localhost to the hostname of the RSA Identity Governance and Lifecycle server, or in a cluster, the SON.
Additionally, you must configure the agent and server to use certificates as described in Help in Security: SSL
Configuration and Authentication.
Before You Begin

SSL connections to AFX servers and remote agents use the certificates in server.keystore. Use these certificates
to create a keystore in WebSphere. These procedures assume that the WebSphere server contains other
keystores, which contain the certificates for secure SSL connections between WebSphere applications, such as
RSA Identity Governance and Lifecycle, and web browsers or web services.
If the WebSphere server does not contain any keystores, you must do the following before configuring SSL the
RSA Identity Governance and Lifecycle :

l Obtain private keys and digital certificates from a trusted CA, such as Verisign, Inc. or Entrust.net.
l In WebSphere, create the keystore.
l Load the private keys and trusted CAs into the keystore.
For instructions, see the WebSphere documentation.
Download the server.keystore File

You can use RSA Identity Governance and Lifecycle to download the server.keystore file.
Procedure
1. Log into RSA Identity Governance and Lifecycle as an administrator, for example, AveksaAdmin.
2. Go to Admin > System > Security.
3. Under Security, click Download.
4. When prompted, click Save.
5. Specify where to save the server.keystore file, and click Save.
6. Copy the file to the WebSphere server.
7. Write down the location of the file. You must specify this location when you create the keystore on the
WebSphere server.
Create a Keystore in the WebSphere Server

To secure communication between the AFX server and RSA Identity Governance and Lifecycle agents, the
WebSphere server running RSA Identity Governance and Lifecycle needs to know about the certificates in the
RSA Identity Governance and Lifecycle server.keystore. You must associate the server and the keystore by
copying the server.keystore file to the WebSphere machine and creating a keystore on WebSphere.
To create a keystore, see your WebSphere documentation. Use the following information when entering keystore
properties:
Property Value
Name Aveksa Agent Keystore
Management Scope <server scope.>
Path <full path to the server.keystore file on the WebSphere server>
Password Av3k5a15num83r0n3
Confirm Password Av3k5a15num83r0n3
Type JKS
Configure SSL in WebSphere

The keystore tells WebSphere where the certificates are. The SSL configuration tells WebSphere to use the self-
signed certificate to secure communication between RSA Identity Governance and Lifecycle and AFX servers or
remote agents.
To configure SSL, see your WebSphere documentation. Use the following information when you enter the
properties:
Property Value
Name Aveksa Agent SSL
TrustStore Name Aveksa Keystore
KeyStore Name Aveksa Keystore
Default Server Alias server

Property Value
Default Client Alias server
Standalone - select server scope
Management scope
Cluster - select cluster scope
Procedure
1. In the WebSphere console, click Security > SSL certificate and key management > SSL configurations.
2. Select the associated Aveksa Agent SSL configuration.
3. Under Additional Properties, select Quality of Protection (QoP) settings.
4. Under Client authentication, select Required.
5. Under Protocol, select TLSv1.2.
6. Click OK to save the changes.
7. Restart WebSphere.
Configure the SSL Port

Configure the SSL port that WebSphere will use for the secure connection.
Procedure
1. In the WebSphere console, configure a web container transport chain using the following settings and
save the transport chain to the master configuration:
Setting Value
Transport Name WCAveksa8444
Transport chain Template WebContainer-Secure
Port Name ACMPort8444
Host *
Port 8444
2. Edit the WCAveska8444 transport chain and modify SSL inbound channel (SSL_4) to use the SSL
configuration specific to this endpoint: Aveksa Agent SSL.
3. Create a new host alias for the default_host using the following settings and save the changes to the
master configuration:
Setting Value
Host *
Port 8444
4. Restart the application server.
Configure SSL for External Communications (Browser or Web

Services to RSA Identity Governance and Lifecycle)
To secure the administration of RSA Identity Governance and Lifecycle through a web browser and to secure the
web services that connect to RSA Identity Governance and Lifecycle, you must configure HTTPS access on the
WebSphere server, if it's not already configured.
Configuration consists of these tasks:

l Create a keystore and configure SSL using certificates from an internal or third-party CA.
l Create a port to use for communication from a browser or web services.
These settings are made in the WebSphere application server.
Create a Keystore on the WebSphere Server

Create a keystore on the WebSphere server to store the certificates for RSA Identity Governance and Lifecycle.
RSA Identity Governance and Lifecycle uses these certificates when communicating with browsers and web
services.
To create a keystore, see your WebSphere documentation. Use the following information when you are entering
the keystore properties:
Property Value
Name Aveksa Keystore
Management Scope <server scope.>
Path <full path to the server.keystore file on the WebSphere server.>
Password <keystore password>
Confirm Password <keystore_password>
Type JKS
Configure SSL in WebSphere

Configure SSL to secure WebSphere connections.
Lifecycle server identifies itself using a certificate. RSA recommends that you use a signed certificate.
A self-signed certificate is installed with the product. This certificate enables an HTTPS connection, but the
client browser always displays a warning before allowing a user to connect. RSA recommends that you replace
the self-signed certificate with a certificate signed by a Certificate Authority (CA).
To configure SSL, see your WebSphere documentation. Use the following information when entering properties:
Property Value
Name Aveksa SSL
TrustStore Name Aveksa Keystore
KeyStore Name Aveksa Keystore
Default Server Alias <server_alias>
Default Client Alias <server alias>
Standalone - select server scope
Management scope
Cluster - select cluster scope

Create an SSL port for WebSphere to communicate with web browsers and web services. By default,
WebSphere uses port 9443.
Procedure
1. In the WebSphere console, configure a web container transport chain using the following settings and
save the transport chain to the master configuration:

Setting Value
Transport Name WCAveksa9443
Transport chain Template WebContainer-Secure
Port Name ACMPort9443
Host *
Port 9443
2. Edit the WCAveska9443 transport chain and modify SSL inbound channel (SSL_4) to use the SSL
configuration specific to this endpoint: Aveksa SSL.
3. Create a new host alias for the default_host using the following settings and save the changes to the
master configuration:
Setting Value
Host *
Port 9443
Configure JAAS Authentication in WebSphere
RSA Identity Governance and Lifecycle authentication sources require the configuration of a corresponding JAAS
module in WebSphere. In a clustered environment, configuration is required on each application server
instance.
RSA Identity Governance and Lifecycle displays configuration properties required to set up the authentication
source in WebSphere in the RSA Identity Governance and Lifecycle user interface under the Admin > System
> Authentication tab for a given Authentication source. Use this list of properties, including any encrypted
password, to set up the JAAS configuration within WebSphere.
For more information, see "Creating a New Authentication Source" in the RSA Identity Governance and Lifecycle
Administrator's Guide.
Procedure
1. Open the WebSphere Administrative Console.
2. From the Security menu, select Global Security.
3. Under Authentication, expand Java Authentication and Authorization Service and select Application
Logins.
4. Click New to create the Login Module Alias:
Authentication Strategy: <Authentication Source Name> This is the name of the authentication source in
RSA Identity Governance and Lifecycle.
5. Click Apply.
6. In the JAAS Login Modules section, click New to define the Login Module class name.
For example: Module class name: com.aveksa.server.authentication.AveksaJndiLoginModule
7. Click Apply.
8. In the Custom properties section, click New.

9. Enter the authentication source parameters values. The values must match those configured for the
authentication source you created in RSA Identity Governance and Lifecycle. The list of configuration
property values will vary, depending on the type of the authentication source and the data used to
configure it.
Custom properties (AD/LDAP examples):

l Authentication Source Name: TestLDAP
l AuthUserAttribute: cn
l BindDn: OU=accounts,DC=com
l BindPassword: In the authentication source display, click Copy Encrypted Password for this
value.
l ConnectionUrl: ldap://<machine-ip>:<port>
l UseSSL: no
l AccountBaseDN: Admin@mycorp.com
l AccountSearchAttribute: cn
l AccountSearchScope: 2
l SearchFilterForAccounts: <optional>
You can strengthen security by using these recommended settings, where possible.
l Check SSL/TLS Settings for Secure Communication Ports

l Enabling Secure Cookies on WebSphere
l Check Security Settings for RSA Governance and Lifecycle
Enable Secure Cookies on WebSphere

In WebSphere you can enable security to prevent cookies from being transmitted in clear text over unencrypted
channels. This ensures secure transmission of data in the cookies.
Before You Begin

Make sure the WCInboundDefaultSecure web container transport chain is enabled. Note down the SSL port
number of this chain.
Procedure
1. In the WebSphere console, from the Servers menu, click WebSphere Application Servers > <server-
name>
2. Under Container Settings, click Session Management.
3. Click Enable Cookies.
4. Enable the Restrict Cookies to HTTPS Sessions setting.
5. Click OK to save the changes.
RSA Identity Governance and Lifecycle is now accessible only over the SSL port configured in the
WCInboundDefaultSecure web container.


tab.
l Security


Chapter 7: WebLogic Installation

Perform the following tasks to install RSA Identity Governance and Lifecycle on a standalone WebLogic server or
in a clustered server environment.
1. Download the Installation Files for WebLogic.

2. Configure WebLogic JVM Settings for RSA Identity Governance and Lifecycle.
3. Configure RSA Identity Governance and Lifecycle Resources on WebLogic.
4. Configure a Non-SSL Port for WebLogic.
5. Install RSA Identity Governance and Lifecycle using the Aveksa EAR File.
6. Install the Workflow Architect EAR File.
7. Confirm the Setting for the Encryption Key Directory.
8. Configure SSL for Internal Communications Between RSA Identity Governance and Lifecycle
Components.
9. Configure SSL for External Communications (Browser or Web Services to RSA Identity Governance and
Lifecycle).
10. Implement Security Best Practices.
Before You Begin
l Make sure your machine meets the prerequisites for hardware, software, and database described in
Chapter 2, Installation Prerequisites.
l You should have a working knowledge of WebLogic, privileges to deploy RSA Identity Governance and
Lifecycle within the environment, and know how to stop and start WebLogic Server instances as
required.
l Confirm that a cluster is already configured for an RSA Identity Governance and Lifecycle deployment.
You need information about each application server instance in the cluster. For background information
about running RSA Identity Governance and Lifecycle in a cluster, see Clustered Application Server and
Oracle RAC Implementation Environments.
l For WebLogic Server versions 10.3.6 through 12.1.3, ensure that the WebLogic Server has been
patched to address WebLogic bug #18633088.
l Add the following Java option to the WebLogic server start-up script:
-Dweblogic.deploy.MaxPostSize=“1610612736”
If You Need a Modified Version of RSA Identity Governance and Lifecycle

You might be required to install a modified version of RSA Identity Governance and Lifecycle under the following
circumstances:

l You use non-default named database user schemas.

l You use non-default database tablespace names.
l To support integration with third-party provisioning systems.
l To implement other custom functionality.
For more information, see the following resources:
l Modifying the Enterprise Archive for information on setting up a customization directory where you can
configure custom RSA Identity Governance and Lifecycle settings for WebLogic.
l The Help for information on customizing settings in the “customization” directory for integration with
any of the following:
l Novell Identity Manager
l Sun Identity Manager
l IBM Tivoli Identity Manager
Clustered Application Server and Oracle RAC Implementation Envir-

onments
The following illustration depicts RSA Identity Governance and Lifecycle deployment in a clustered application
server environment, and implementing an Oracle Real Application Cluster (RAC).
96 Chapter 7: WebLogic Installation

RSA Identity Governance and Lifecycle in a Clustered Application Server Environment

You can install RSA Identity Governance and Lifecycle on multiple application server instances in a cluster. Each
instance running RSA Identity Governance and Lifecycle is called a node. The application server administers the
nodes collectively as a cluster that shares a common database to provide a scalable environment. Nodes self-
register with the database on startup.
Each node can support up to 250 client sessions. There are two types of nodes:
l A single System Operations Node (SON), which handles operations, such as data collections, agent
management, review generation, and policy processing.
l One or more general nodes, which handles user interface processing.
For more information, see the Help topic, "Managing Server Cluster Nodes."

Oracle RAC for an RSA Identity Governance and Lifecycle Deployment

An Oracle Real Application Cluster (RAC) database has more components and more complexity than a single-
instance Oracle database. Familiarize yourself with these components so you can make appropriate decisions for
your environment.
The following describe each RAC component and recommendations for RSA Identity Governance and Lifecycle:
l Oracle RAC Database Instances — An Oracle RAC installation typically includes two or more database
instances, each with its own memory and local working cache. Each node requires two network
interfaces to communicate with both application servers on the public network and private network that
is used for both shared storage and the cluster .
RSA recommends that each database node has a local hard disk that holds the individual Oracle
clusterware and Oracle database homes in addition to the operating system and local swap files.
l Private Network — The private network used for coordinating cluster activities and the network that
accesses the shared storage system. The private network allows the Oracle cluster to the access Cluster
Ready Services (CRS)/Voting disk. Because RSA Identity Governance and Lifecycle operates in a mixed
Online Transaction Processing (OLTP) and Decision Support System (DSS) mode, many installations
benefit from a faster 10-Gbit network to support the caching requirements of DSS operations such as
collections and report generation.
l Shared Storage — RSA Identity Governance and Lifecycle supports Storage Area Network (SAN) systems
with multiple disk volumes. SANs with RAID 5 or RAID0+1 provide the required read-write performance
for the Oracle RAC.
The shared storage system, along with Oracle Automatic Storage Management (ASM), provides three
types of storage for the cluster that will be assigned to Logical Unit Numbers (LUN). Traditional Oracle
tablespace storage will occupy most of the space and will be stored in the LUN "VOL1." A second LUN,
will be created for cluster activities and will be assigned to the LUN "CRS1."
The third LUN will provide a general purpose "cluster-aware" file system that will be shared with all of
the members of the cluster and will be assigned to the LUN "FS1." Oracle requires this "cluster-aware"
file system be used when setting up Oracle directories in a cluster. Because RSA Identity Governance
and Lifecycle requires the AVEKSA_EXPORTIMPORT_DIRECTORY, we recommend a configuration that
uses Oracle Automatic Storage Management Cluster File System (Oracle ACFS) to create a mountable
volume usable by the operating system itself.
Download the Installation Files for WebLogic
You must download the installation software to the WebLogic machine.
Procedure
1. Log on to the machine hosting the WebLogic application server.
2. Choose a download directory (/opt for example).
3. Download the installation files:


f. Click Continue.

l ACM-WebLogic-<product version>.tar
4. Expand the tar file:
cd /opt
tar -xvf ACM-WebLogic-<product version>.tar
Note: On Solaris, use a tar utility that handles long filenames such
as GNU tar.
This step creates an ACM-WebLogic directory that includes all software components required for the
installation. The directory location is referred to as DISTRIBUTION in this chapter.
Configure WebLogic JVM Settings for RSA Identity Governance and

Lifecycle
Use the WebLogic console to perform all installation and configuration steps. See your WebLogic administrator
for the URL and access credentials.
Note: Restart the application server instance after you change JVM settings described in this section.
Procedure
1. Start WebLogic using the domain 'startWebLogic.sh' command. For example:
$DOMAIN_HOME/bin/startWebLogic.sh
2. From your browser, access the WebLogic Administration Console using the following URL:
http://<hostname>:7001/console
3. Complete the remaining tasks in this chapter.
Configure JVM Settings
Use the WebLogic console to configure the appropriate JVM settings for your deployment.
Note: RSA Identity Governance and Lifecycle requires UTF-8 character encoding. Ensure that the JVM settings
are set to UTF-8 for each managed server on which it is deployed, standalone or cluster.
Procedure

1. In the WebLogic console, to select the server, click Environment > Servers > Select server.
3. Select Configuration tab > Server Start tab.
4. Under Arguments, perform the following steps:
a. Enter the following to set the character encoding:
-Dclient.encoding.override=UTF-8 -Dfile.encoding=UTF-8
b. Add the following setting to specify the protocol, such as http or https, that your deployment
uses:
-Dwp-client-protocol=<protocol>
c. In deployments that use a load balancer, such as a clustered environment, add the following
setting:
-Dwp-client-hostname=<hostname>
d. If your deployment does not use the default port setting for HTTP, add the following setting:
-Dwp-client-hostport=<hostport>
5. Click Save.
Configure Application Server Memory

RSA Identity Governance and Lifecycle has minimum JVM memory requirements. Ensure that the settings are
adequate for each managed server on which it is deployed, standalone or cluster. Also ensure your hardware
has sufficient physical memory for those requirements. Use this procedure to modify the following JVM memory
parameters for RSA Identity Governance and Lifecycle:
l Maximum JVM heap Size. 8 GB is the minimum requirement for a production environment. Additional
memory may be required based on the size of the data and the number of concurrent users. For
example, 32 GB is expected to support up to 300 concurrent users.
The JVM argument is –Xmx. For example (8GB): –Xmx8192m
Use one of the two following methods to set JVM arguments:
l Edit the WebLogic Domain Environment Startup Script

l Set JVM arguments in the Admin Console
If you use custom scripts to start the WebLogic application server, these methods might not map to your
environment. Consult the WebLogic administrator on how the JVM arguments are set for your environment.
Edit the WebLogic Domain Environment Startup Script
The JVM startup options are in the setDomainEnv.sh script by default. You can edit the JVM settings for the
domain in which you will deploy RSA Identity Governance and Lifecycle. For example, from $WEBLOGIC_
HOME/user_projects/domains/<domain_name>/bin, you can add commands for USER_MEM_ARGS near the
beginning of the setDomainEnv script, where WL_HOME is set, to override the default memory settings:
USER_MEM_ARGS=" –Xmx8192m "
export USER_MEM_ARGS

If you require other memory settings, make sure you retain those settings along with RSA Identity Governance
and Lifecycle settings. For example:
USER_MEM_ARGS=" –Xms256m -Xmx8192m -XX:CompileThreshold=8000 -

XX:PermSize=48m "
Set JVM Arguments in the Admin Console
To set the JVM arguments using this method, log in to the Admin Console and perform these steps:
Procedure
1. To select the server, click Environment > Servers > Select server.
2. On the Configuration tab, select Server Start tab.
3. In the Arguments field, add: -Xmx8192m
Configure JTA Timeout Setting

The JTA Transaction timeout controls how much time WebLogic waits for a SQL transaction to finish. In most
cases 30 seconds is sufficient; however, for systems under load or that have a large user, rule, role, or
workflow setup, this setting is too low and will cause errors to display. To avoid this setting, increase the
timeout setting.
Procedure
1. Open WebLogic admin console.
2. Go to Services > JTA.
3. Change the Timeout setting from 30 (default) to 120.
Configure RSA Identity Governance and Lifecycle Resources
Perform all installation and configuration steps from the WebLogic Administration Console. All values are
expected to be set to the default values, unless otherwise specified. Make sure the application server resources
are created with the correct scope, which is different between clusters and standalone servers. When you
configure resources for a cluster, you might need to synchronize nodes or restart nodes. See the Database
Configuration Values for more information.
Procedure
1. Start WebLogic using your domain 'startWebLogic.sh' command. For example:
$DOMAIN_HOME/bin/startWebLogic.sh
2. From your browser, access the WebLogic console. For example:
http://<hostname>:7001/console
3. Complete the tasks in this section for your domain.
Create Security Realm Users and Groups

Security realm users and groups allow you to create security policies for application server resources, data
sources for example. RSA Identity Governance and Lifecycle defines two users in the WebLogic security realm:

l aveksaUser, which is assigned to the the acmUsers group

l workpoint, which is assigned to the WorkPointUsers group
Note: If you change security realm user information after the RSA Identity Governance and Lifecycle EAR has
been deployed, you must change corresponding settings in the EAR and then redeploy the EAR. See Changing
the Security Realm User and Group Information for more information.
Procedure
1. Log on to the WebLogic console.
2. Select Security Realms.
3. Select myRealm > Users and Groups tab and create the users and groups as follows:
l Create a acmUsers group from the Groups tab:
a. Click New.
b. Enter:
Name: acmUsers
Description: acm runtime user
c. Click OK.
l Create a WorkPointUsers group from the Groups tab:

a. Click New.
b. Enter:
l Name: WorkPointUsers
l Description: acm runtime user
c. Click OK.
l Create an aveksa user from the Users tab:

a. Click New.
b. Enter:
a. Name: aveksaUser
b. Description: acm default runtime user
c. Password: Aveksa123
c. Click OK.
l Create a workpoint user from the Users tab:

a. Click New.
b. Enter:
Name: workpoint
Description: Workpoint user
Password: w0rkp0int (0=zero)
c. Click OK.

4. Add the users you created to the groups you created from the Users and Groups > Users tab:
l Add the aveksaUser user to the acmUsers group:
a. Click aveksaUser.
b. Select the Groups tab.
c. Move acmUsers from the Available list to the Chosen list.
d. Click Save.
l Add the workpoint user to the acmUsers and WorkPointUsers groups:

a. Click workpoint.
b. Select the Groups tab.
c. Move acmUsers and WorkPointUsers from the Available list to the Chosen list.
d. Click Save.
Create the JDBC Data Sources

You must create the JDBC data sources RSA Identity Governance and Lifecycle uses to access the database. The
steps for creating the JDBC data sources vary depending on whether your WebLogic installation uses a standard
standalone Oracle database or an Oracle RAC implementation. Review the steps before proceeding.
The following default RSA database user schema names are used in this task:
Aveksa Statistics Reports. If you remove or disable Statspack on your database, remove the AVPERF data
source and restart the database.
Note: If you created the database instance with non-default names, you must use the same user names and
passwords when you create the JDBC data sources. See the Database Setup and Management Guide to ensure
that the database instance meets the RSA Identity Governance and Lifecycle product requirements. To configure
JDBC data sources, you need the Oracle SID, Oracle listener hosts, Oracle listener port, and Oracle service
name. In addition to configuration information, you need to know if the Oracle database being used is a standard
Oracle or Oracle RAC implementation. You might require the assistance of your Oracle database administrator
(DBA) to provide the information needed to create the data sources or resolve any issues with connectivity.
Repeat this procedure for the data sources listed in the following table. This table provides additional
information needed for the data source creation process. Each created data source yields an Oracle connection
URL to test. If the data source is configured incorrectly, the connection test fails. An Oracle DBA might be
necessary to resolve the issue.
Default Data Source Name Data Source JNDI Name URL Suffix

AVDB jdbc/avdb avdb
AVDWDB jdbc/avdwdb avdwdb
ACMDB jdbc/acmdb acmdb
AVPERF jdbc/avperf avperf
Procedure


2. From the Services menu, select Data Sources.
3. Click New to create a data source. Choose the data source type based on your Oracle environment:
l Generic Data Source for an Oracle non-RAC standalone database
l Gridlink Data Source for an Oracle RAC database
The Oracle RAC configuration may have two options for providing Oracle connection
information: Provide the complete connection URL or provide connection information
for WebLogic to create the URL.
4. Configure the data source using the following table of configuration details. Use the default values
unless otherwise specified.
Standalone Database RAC Database
Data Source Name from preceding Data Source Name from preceding
Name
table table
Scope Global Global
JNDI Name JNDI Name from preceding table JNDI Name from preceding table
Driver (Thin) for Instance connections (Thin) for GridLink connections
AVDB, ACMDB, and AVPERF - AVDB, ACMDB, and AVPERF -
Supports Global Selected Selected
Transactions
AVDWDB - Deselected AVDWDB - Deselected
One Phase Commit Selected Selected
Database/Service Name
Host Name
Port See DBA for Oracle Connection Information
Database User
Password
URL Value is populated by WebLogic May be populated or set explicitly
5. Test the Configuration. If the connection test fails, review the Oracle connection information.
6. Under Target, select the target server or cluster.
7. Save the configuration.
8. Repeat steps 3-7 for each of the data sources.
9. Edit the configuration for each data source:
a. Go to the Connection Pool tab, expand the Advanced settings, then deselect Wrap Data Types.
b. Configure the Set Maximum Capacity value according to the following table:
Data Source Maximum Capacity Value
AVDB 300
ACMDB 15
AVDWDB 50
AVPERF default value
10. (Optional) Secure each data source with a security policy. You can enable security after installing RSA
Identity Governance and Lifecycle.

Note: The settings here are dependent on the users and groups defined in Create Security Realm Users
and Groups.
a. Select the new data source. (For example, AVDB).

b. Select the Security tab, then the Roles sub-tab.
c. Select New, and enter a security policy name: acmUsers.
d. Click OK.
e. Select the Policies sub-tab.
f. Select Add Conditions.
l Predicate List: Select Role.
l Role Argument Name: acmUsers
g. Select Add.
h. Select Finish.
i. Select Save.
j. Restart WebLogic.
Java Messaging Service Configuration

You must configure all Java Messaging Service (JMS) settings referenced in this section.
Procedure
1. To create a JMS server or servers. Click Services > Messaging > JMS Servers > New.
On a standalone system, configure a single server with the AdminServer as the target. For a cluster,
create a JMS server for each server instance or node. See the Database Configuration Values for
installing in a clustered environment.
l Name: acmJMSServer1
l Persistent Store: Select a preconfigured Persistent Store or click New to create one with the
required information for the given persistent store type. Set the persistent store target to match
the target for this JMS server.
l New (Persistent Store) Choose Type: File Store or JDBC Store
l Name: Provide a name for the store. For example: Server1FileStore
l Target: Choose the target server instance. Choose the server for a cluster configuration.
For example: Node1
l Directory (File Store): Provide the directory on the server where the persistent store is
kept.
l Data Source (JDBC Store): <Configured datasource>
Do not select a Data Source that supports global transactions.
l Prefix Name (JDBC Store): Prefix for the table name for the store. For example, server1,
would result in table SERVER1WLSTORE.

2. Create a new JMS Module. Click Services > Messaging > JMS Modules > New.
l Name: acmJMSModule
l Descriptor File Name: Leave blank.
l Target: Choose the target server or the cluster name.
3. Create a subdeployment. Click acmJMSModule > Subdeployment Tab > New.

l Name: acmSubDeployment
l Targets: Choose the JMS Servers Target(s). Select multiple Target JMS Servers for a cluster, for
example: acmJMSServer1, acmJMSServer2, and so on.
4. Add the required resource to the acmJMSModule. Select acmJMSModule, select the Configuration tab for
each new resource, and click New.
a. New Queue:
l Type: Queue or a Distributed Queue for a clustered environment
l Name: wpUtilQueue
l JNDI Name: queue/wpUtilQueue
l Subdeployment: Select acmSubDeployments
l Target: Required targets are selected by default as part of the subdeployment.
5. Add the following new resources to the acmJMSModule:

a. New Connection Factory
l Type: Connection Factory
l Name: acmConnectionFactory
l JNDI Name: jms/acmConnectionFactory
l Select Advanced Targeting.
l Subdeployment: Select acmSubDeployment
b. Edit the acmConnectionFactory: From the Default Delivery tab, set the Default Delivery Mode to
Non-Persistent.
c. New Topic:
l Type: Topic or Distributed Topic for a clustered environment.
l Name: acmMessageTopic
l JNDI Name: topic/acmMessageTopic
l Subdeployment: Select acmSubDeployment
Install RSA Identity Governance and Lifecycle Using the Aveksa EAR
File
This section describes how to install the RSA Identity Governance and Lifecycle application by using the Aveksa
EAR file.
Before you begin
In a clustered environment, consider the following:

l Identify which node is the system operations node (SON). By default, the initial server instance is the
system operations node (SON) on any newly created cluster.
l Installation requires a single connection to the database for setup and migration. Use a single node and
make sure only one server instance is running. While this can be any node, RSA recommends using the
SON node for the installation or upgrade process.
l If migrating or patching a clustered deployment, you are required to run the SON without any other
active nodes before using the system. The SON must be started after installation is complete to properly
instantiate any workflow updates and ensure that any new RSA Identity Governance and Lifecycle
security model changes are initialized.
Procedure
2. Select Deployments > Install.
3. Browse to aveksa.ear. For example: ACM-WebLogic /aveksa.ear. The path may differ for a hotfix or a
customized aveksa.ear.
4. Install this deployment as an application.
5. (For clusters only) Select deployment targets: cluster.
6. In the Set Name field, enter: aveksa
7. Choose the default selection: Copy this application to every target for me under Source accessibility.
8. In Additional configuration, choose: No, I will review the configuration later.
9. Start the RSA Identity Governance and Lifecycle application. In a cluster, start the application on the
single designated deployment node only.
In a cluster, the first managed server you start deploys and initializes the database schema, which
might take several minutes.
You can check installation progress by viewing the WebLogic Admin Server log file. See Troubleshooting
a WebLogic Installation on page 151 for more information on log files.
10. Validate the installation by accessing RSA Identity Governance and Lifecycle from
http://localhost:7001/aveksa/main.
In a cluster, verify your installation before starting additional nodes.
Once the SON node is started and validated, all other nodes can be started. For information on how to
manage RSA Identity Governance and Lifecycle instance nodes in the cluster, see the Help topic,
"Managing Server Cluster Nodes."
Install the Workflow Architect EAR File
This task describes how to install the RSA Identity Governance and Lifecycle Workflow Architect application. You
can use the Workflow Architect to view and edit workflows for change requests.
During the deployment process, a cluster requires a single connection to the database for setup and migration.
Make sure you use a single instance and ensure that no other instances are running.
Procedure


2. Select Deployments > Install.
3. Browse to aveksaWFArchitect.ear. For example: ACM-WebLogic /aveksaWFArchitect.ear. The path may
differ for a patch.
4. Install this deployment as an application.
5. (For clusters only). Select deployment targets: cluster.
6. Choose the default: Copy this application to "every target for me" under Source accessibility.
7. In Additional configuration, select: No, I will review the configuration later.
8. Click Finish.
The Key Encryption Key (KEK) is the key used to encrypt all other encryption keys. The installation (or upgrade)
creates a unique KEK and stores it in the encryption key directory. The default location of the directory is
/home/oracle/security. If the default directory is not available or you want to set a different directory, you must
create the directory, and then specify the location in a Java system variable.
Procedure
1. Log in to the system as administrator with root privileges.
running.
3. Set a Java system property "rsavialg.security.keydir" to the directory where the encryption key is stored.
The location of this property depends on the platform you are running on and also whether RSA Identity
Governance and Lifecycle is standalone or running in a cluster.
There are two ways to set JVM arguments in WebLogic installations. These methods might not map to
your environment if you use custom scripts for starting a WebLogic application server instance. See
your WebLogic administrator to configure the JVM setting for your environment.
l Edit the WebLogic Domain startup environment script. This is typically done on a standalone
system and is required if using the AdminServer as the instance where you are deploying RSA
Edit the setDomainEnv.sh file for the domain in which you will be deploying the RSA Identity
Governance and Lifecycle application.
For example, from $WEBLOGIC_HOME/user_projects/domains/<domain_name>/bin, add the

following settings to the beginning of the setDomainEnv script, where WL_HOME is set.

JAVA_OPTIONS="$JAVA_OPTIONS -Drsavialg.security.keydir=<directory path for the

encryption key>"
export JAVA_OPTIONS
JAVA_OPTIONS="$JAVA_OPTIONS
-Drsavialg.security.keydir="/wls/masterkeystorage"
For example, in a clustered environment:
JAVA_OPTIONS="$JAVA_OPTIONS -Drsavialg.security.keydir="/wls/masterkeystorage"
l Use the Administration Console to specify JVM arguments for a server instance. This is typically
used if your servers are managed through NodeManager.
From the Admininistration Console:

1. Click Environment > Servers > Select server.
2. Click Configuration tab > Server Start tab.
3. Add the startup setting -Drsavialg.security.keydir=<directory path for the encryption
key> to the Arguments field .


Procedure
1. Add a java system property named "rsavialg.security.strict.permissions.disabled" property and set the
value to "true" as shown for the platform type:
There are two ways to set JVM arguments in WebLogic installations. These methods might not map to
your environment if you use custom scripts for starting a WebLogic application server instance. See
your WebLogic administrator to configure the JVM setting for your environment.
l Edit the WebLogic Domain startup environment script. This is typically done on a standalone
system and is required if using the AdminServer as the instance where you are deploying RSA
Edit the setDomainEnv.sh file for the domain in which you will be deploying the RSA Identity
Governance and Lifecycle application.
For example, from $WEBLOGIC_HOME/user_projects/domains/<domain_name>/bin, add the

following settings to the beginning of the setDomainEnv script, where WL_HOME is set.
JAVA_OPTIONS="$JAVA_OPTIONS -Drsavialg.security.strict.permissions.disabled=true"

export JAVA_OPTIONS
JAVA_OPTIONS="$JAVA_OPTIONS
-Drsavialg.security.strict.permissions.disabled="true"
For example, in a cluster environment:
JAVA_OPTIONS="$JAVA_OPTIONS -Drsavialg.security.strict.permissions.disabled="true"
l Use the Administration Console to specify JVM arguments for a server instance. This is typically
used if your servers are managed through NodeManager.
From the Admininistration Console:

1. Click Environment > Servers > Select server.
2. Click Configuration tab > Server Start tab.
3. Add the startup setting -Drsavialg.security.strict.permissions.disabled=true to the
Arguments field .
If the directory already exists, set its permissions such that the user (owner of the process under which
RSA Identity Governance and Lifecycle is running) has “rwx” access into this directory. The owner of the
directory need not be the same as the owner of the application process, but the owner of the application
process must be able to read and write into this directory. This means “rwx” permissions have to be set
for the appropriate file permission field (owner, group, all) , which will allow the application process full
access.
If the directory does not exist, it is recommended that you create it. Set up the permissions on the
directory as specified in the previous item.
If the directory does not exist and you do not create it, the application will attempt to create the directory
on first startup using default permissions and the directory will be owned by the same user as the
application process.


above).
Error Messages
encryption key directory. The table lists default directory paths for the encryption key directory

KEK_ERROR_ The parent directory /home/oracle for the Create the directory structure, set
PARENT_ specified encryption key storage directory permissions to allow RSA Identity
DIRECTORY_DOES_ /home/oracle/security does not exist. Governance and Lifecycle to read from


and write to the directory, and specify
NOT_EXIST
the encryption key directory again.
KEK_ERROR_ Change permissions on the specified
The parent directory /home/oracle for the
PARENT_ encryption key directory to allow RSA
DIRECTORY_IS_ Identity Governance and Lifecycle to
/home/oracle/security is not writable.
NOT_WRITABLE write to the directory.
The parent /etc/hosts for the specified encryption
KEK_ERROR_ Specify a directory path for the
key storage directory /etc/hosts/security is a file,
PARENT_IS_A_FILE encryption key directory.
not a directory.
KEK_ERROR_FILE_ Specify a directory location, not a file
ALREADY_EXISTS location.
/etc/hosts.
Create the directory, set permissions
KEK_ERROR_COULD_ to allow RSA Identity Governance and
Could not create the encryption key storage
NOT_CREATE_ Lifecycle to read from and write to the
directory /home/oracle.
DIRECTORY directory, and specify the encryption
KEK_ERROR_ Verify that directory permissions allow
DIRECTORY_IS_ RSA Identity Governance and Lifecycle
/home/oracle is not writable.
NOT_WRITABLE to write to the directory.
Create the directory, set permissions
KEK_ERROR_ to allow RSA Identity Governance and
DIRECTORY_DOES_ Lifecycle to read from and write to the
/home/oracle does not exist.
NOT_EXIST directory, and specify the encryption
Verify that directory permissions allow
RSA Identity Governance and Lifecycle
The encryption key storage directory to write to the directory.
KEK_ERROR_
INVALID_ Alternatively, you can set a system
permissions. Please refer to the installation
DIRECTORY_
documentation for a system property that can be property to remove this restriction.
PERMISSIONS See "Using Non-restrictive Mode for
set to remove this restriction.
the Encryption Key Directory" in the
previous section.
Configure SSL for Internal Communication Between RSA Identity

Governance and Lifecycle Components
RSA Identity Governance and Lifecycle contains the server.keystore file which is used as a keystore and
truststore. This file contains
l RSA Identity Governance and Lifecycle Certificate Authority (CA)

l RSA Identity Governance and Lifecycle self-signed server certificates
l Chained trusted certificate of the RSA Identity Governance and Lifecycle CA

RSA Identity Governance and Lifecycle trusts connections with AFX servers and remote agents because their
certificates have been signed by the RSA Identity Governance and Lifecycle CA.
To enable SSL between RSA Identity Governance and Lifecycle and AFX or agents, you must make the
server.keystore available to WebLogic by completing the following tasks:
Procedure
1. Download the server.keystore file from RSA Identity Governance and Lifecycle to the WebLogic server.
2. Import the certificates from the downloaded server.keystore into the WebLogic keystore.
3. Configure the SSL port.
The following sections describe how to perform these tasks.
Before You Begin

These procedures assume that the WebLogic keystores also contain the certificates used to secure SSL
connections between WebLogic applications, such as RSA Identity Governance and Lifecycle, and web browsers
or web services.
If the WebLogic server does not contain the keystores and certificates required to use SSL, you must perform
the following configuration tasks before you configure the RSA Identity Governance and Lifecycle application to
use SSL:
l Obtain private keys and digital certificates from a reputable certificate authority, such as Verisign, Inc.
or Entrust.net.
l Create the identity keystore and the trusted keystore.
l Load the private keys and trusted certificate authorities (CAs) into the keystores.
For instructions on how to perform these tasks, see the WebLogic documentation.
Download the server.keystore File

You can use RSA Identity Governance and Lifecycle to download the server.keystore file.
Procedure
1. Log on to RSA Identity Governance and Lifecycle as an administrator user, for example, AveksaAdmin.
2. Go to Admin > System > Security.
3. Under Security, click Download.
4. When prompted, click Save.
5. Specify where to save the server.keystore file, and click Save.
6. Copy the file to the WebLogic server.
7. Write down the location of the file. You must specify this location when you import the certificates into
the keystore on the WebLogic server.
Import the RSA Identity Governance and Lifecycle Certificates into the
WebLogic Keystores
To communicate with the AFX server and RSA Identity Governance and Lifecycle agents, the WebLogic server
running RSA Identity Governance and Lifecycle needs to know of the certificates contained in the
server.keystore file. Use the WebLogic keytool utility to import the certificates.
WebLogic contains two keystores: an identity keystore and a trusted keystore. Use the keytool to import the

trusted certificate (also known as the CA) into the trusted keystore and the private key into the identity keystore.
If your WebLogic server uses the same keystore trust and identity, you can import the private key and the
trusted certificate into the single keystore.
The following sections provide the command parameters to use when you run the keytool.
To import the private key into the identity keystore
Procedure
Log on to the WebLogic server and type the following at a command prompt:
keytool -importkeystore -srcalias server -srckeypass Av3k5a15num83r0n3 -srckeystore <directory_

path>/server.keystore -srcstorepass Av3k5a15num83r0n3 -srcstoretype jks -destalias server -
destkeypass Av3k5a15num83r0n3 -destkeystore <dest-keystore> -deststorepass <dest-storepass>
where
l <directory_path>/server.keystore is the full directory path to server.keystore.

l <dest-keystore> is the location of identity keystore.
l <dest-storepass> is the password of the identity keystore.
To import the trusted certificate into the trusted keystore
Procedure
keytool -importkeystore -srcalias aveksa_ca -srckeypass Av3k5a15num83r0n3 -srckeystore <directory_

path>/server.keystore -srcstorepass Av3k5a15num83r0n3 -srcstoretype jks -destalias aveksa_ca -
destkeystore <dest-keystore> -deststorepass <dest-storepass>
where
l <directory_path>/server.keystore is the full directory path to server.keystore.

l <dest-keystore> is the location of trusted keystore.
l <dest-storepass> is the password of the trusted keystore.
To import the private key and the trusted certificate into the same keystore
Procedure
keytool -importkeystore -srckeystore <directory_path>/server.keystore -destkeystore <dest-keystore>

-srcstorepass Av3k5a15num83r0n3 -deststorepass <dest-storepass>
where
l <directory_path>/server.keystore is the full directory path to server.keystore

l <dest-keystore> is the location of identity keystore.
l <dest-storepass> is the password of the identity keystore.

Configure the SSL port that WebLogic will use for the secure connection.
Procedure

1. In WebLogic, create a new network channel using the following settings. In the WebLogic console, the
channnel settings are typically found under Server > Protocols. See the WebLogic documentation for
details on performing this task.
Setting Value
Name Aveksa8444
Protocol https
Listen Port 8444
External Listen Port 8444
Two Way SSL Enabled Checked
Client Certificate Enforced Checked
Custom Channel Private Key Alias server
Custom Channel Private Key Pass Phrase Av3k5a15num83r0n3
Confirm Custom Channel Private Key

Av3k5a15num83r0n3
Pass Phrase
Configure SSL for External Communications (Browser or Web

Services to RSA Identity Governance and Lifecycle)
The WebLogic server uses HTTPS to secure the administration of RSA Identity Governance and Lifecycle through
a web browser, and to secure RSA Identity Governance and Lifecycle web service connections. If HTTPS is not
already configured, you need to configure SSL and enable the SSL listening port for HTTPS. Use certificates that
you obtained from a third-party or internal CA.
RSA Identity Governance and Lifecycle uses the SSL/TLS protocol to secure communications from a browser or
web services on Port 8443.
These settings are in the WebLogic application server. Use the latest available version of TLS to provide the most
secure communications.
Procedure
1. Use the following settings to configure the port. The channel settings are typically found in the
WebLogic console under Server > Protocols.
Setting Value
Name Aveksa8443
Protocol https
Listen Port 8443
External Listen Port 8443
Two Way SSL Enabled Checked
Client Certificate Enforced Unchecked
Custom Channel Private Key Alias server
Custom Channel Private Key Pass Phrase Av3k5a15num83r0n3
Confirm Custom Channel Private Key

Av3k5a15num83r0n3
Pass Phrase

Configure JAAS Authentication in WebLogic
RSA Identity Governance and Lifecycle authentication sources require the configuration of a corresponding JAAS
module in WebLogic. In a clustered environment configuration is required on each application server instance.
RSA Identity Governance and Lifecycle displays configuration properties required to set up the authentication
source in WebLogic in the RSA Identity Governance and Lifecycle user interface under the Admin > System >
Authentication tab for a given Authentication source. Use this list of properties, including any encrypted
password, to set up the JAAS configuration within WebLogic. For more information, see the Help topic, "Creating
a New Authentication Source."
You may require additional authorization sources for your particular environment.
The configuration is typically stored in a jaas config file and the information takes the following form:
AuthenticationSourceName { moduleClass required
<list of name value pairs>
"debug"="false" ;
} ;
The AuthenticationSourceName is the name of the authentication source in RSA Identity Governance and
Lifecycle. Enter the authentication source parameter names and values. The values must match those
configured for the authentication source you create in RSA Identity Governance and Lifecycle.
Custom properties (AD/LDAP examples):
Authentication Source Name: TestLDAP
l AuthUserAttribute: cn
l BindDn: Admin@mycorp.com
l BindPassword: In the authentication source display, click Copy Encrypted Password for this value.
l ConnectionUrl: ldap://<machine-ip>:<port>
l UseSSL: no
l UserBaseDN: OU=accounts,DC=mycorp,DC=com
l UserSearchAttribute: cn
l UserSearchScope: 2
l SearchFilterForUsers: <optional>
Example information entered in the JAAS configuration file where the ACM module name is:
com.aveksa.server.authentication.AveksaJndiLoginModule.
For the example above the information in the jaas configuration file would look like:
TestLDAP{
com.aveksa.server.authentication.AveksaJndiLoginModule required
"AuthUserAttribute"="cn"
"BindDn"="OU=accounts,OU=admins"

"BindPassword"="myencryptedpassword"
"ConnectionUrl"="ldap://<machine-ip>:<port>"
"UseSSL"="no"
"UserBaseDN"="Admin@mycorp.com"
"UserSearchAttribute"="cn"
"UserSearchScope"="2"
"debug"="false";
};
For a test authentication source, in this example named TestAuthProvider, add the following to jaas.conf:
TestAuthProvider{
com.aveksa.server.authentication.TestLoginModule required
"debug"="false";
};
The configuration information is stored in a JAAS configuration file that is referenced by the WebLogic
application server. If your WebLogic server or servers in a clustered environment do not currently use a JAAS
configuration file, create a jaas.conf file. Enter the authentication configuration information in the JAAS
configuration file.
You must restart of the server for the settings to take effect. If this is a new file you have created, you must
identify the new file to the application server by using the following JAVA argument at startup:
-Djava.security.auth.login.config=/<path>/jaas.conf
This can be added to the JAVA_PROPERTIES in the setDomainEnv.sh script for the managed server, which is the
default environment script typically used to start a WebLogic server.
It may also be specified in the “Arguments” field for the “Start Server” tab for the server configuration. Consult
your WebLogic administrator for the appropriate place to add arguments at startup for your application server.
In a clustered environment each managed server must reference a valid JAAS configuration. If RSA Identity
Governance and Lifecycle cannot find the configured JAAS authentication at login time, the following error
message appears:
No Configuration was registered that can handle the configuration named <AuthenticationSourceName >
Validate the jaas configuration file and that the managed server has been configured for and can locate the jaas
configuration file. This can be added to the JAVA_PROPERTIES in the setDomainEnv script for the server. Also
validate that the name is correct in the config file.
Check Recommended Security Settings
RSA recommends that you follow these security practices.
l Check SSL/TLS Settings for Secure Communication Ports

l Enable Secure Cookies

Enable Secure Cookies on WebLogic

In WebLogic you can enable security to prevent cookies being transmitted in clear text over unencrypted
channels. This ensures secure transmission of data in the cookies.
When you upgrade RSA Identity Governance and Lifecycle, you override the secure cookie setting. Make sure
you enable secure cookies after upgrading RSA Identity Governance and Lifecycle.
Procedure
1. Log in as root.
2. Open the weblogic.xml file that is located in the aveksa.war/WEB-INF directory path.
3. Add the secure cookie session descriptor:
<session-descriptor>
<cookie-secure>true</cookie-secure>
</session-descriptor>
4. Save the file.

5. Recreate the RSA Identity Governance and Lifecycle EAR and redeploy the EAR. See Install RSA Identity
Governance and Lifecycle Using the Aveksa EAR File for more information.

tab.
l Security


Chapter 8: Access Fulfillment Express (AFX)

Installation
If you are running RSA Identity Governance and Lifecycle on a Software Bundle, WebSphere server, or
WebLogic server, and you purchased an AFX license, you must manually install AFX.
See the section that applies to your installation scenario:
Scenario Section
Install AFX on your appliance or soft- Install the Local AFX Server on an Appliance or a Software
appliance server Bundle Server Using the Installation Script
Install AFX on a WebSphere or WebLogic
Install the Local AFX Server from a Downloaded Local AFX Server
server
Install an additional AFX server instance on a
Install an Additional AFX Server Instance on a Non-AFX-Host
host where RSA Identity Governance and
Server
Lifecycle is not installed (remote host)
Install AFX connector packages See Install the AFX Connector Packages.
If you purchased an RSA Identity Governance and Lifecycle appliance with an AFX license, AFX is already
installed on the appliance. You can enable AFX you are ready to use it. For instructions on enabling AFX, see
"Specifying System Settings" in Help.
See AFX Hardware and Software Requirements before installing AFX and verify that your deployment meets all
requirements.
AFX Hardware and Software Requirements
When RSA Identity Governance and Lifecycle and AFX are installed on different hosts, follow the guidelines in
this section. When AFX is installed on the same physical system as the RSA Identity Governance and Lifecycle,
use the higher values in the guidelines. For example, if base RSA Identity Governance and Lifecycle installation
requires 16GB of RAM and AFX installation requires 32GB, use 32GB.
Storage
Follow the guidelines below to calculate the amount of storage required by your installation:
AFX Component Storage Requirement

Enterprise Service Bus (ESB) Installation 4 GB
Installation Archive and Initial Deployed Server
1 GB
Footprint
5 MB per connector
Connector
Example: 1,000 Connectors ~ 5 GB
10 MB per connector
Connector Log Files
Example: 1,000 Connectors ~ 10 GB
Note: Cap log file sizes to avoid filling disk space. To further reduce the risk of filling disk space, you should

also employ a monitoring tool. Each connector will consume on average 1 MB of disk space daily. The actual
amount will vary based on the volume of transactions.
Example calculated storage requirement: 4 GB + 1 GB + 5 GB + 10 GB = 20 GB Total
Random Access Memory (RAM)

32 GB is the minimum requirement for a production environment. The requirement varies depending on the
total number of connectors and the transaction volume.
Swap Space
Set to half (1/2) of Physical Memory — This value is set automatically by the application server. You must adjust
manually.
Processor
Processor requirements for deployment environments are listed as follows:
Environment Processor Requirement

A development environment is intended for doing the
deployment work, staging, and functional testing for Dual Intel dual-core Xeon processors (E3110) running
example. It is not for use in large multi-user at 3.0GHz on a 1333MHz FSB
deployments.
A production environment is intended for typical
Dual quad core Intel Xeon processors (E5420) running
enterprise deployment of up to 500 concurrent users,
@ 2.5GHz on a 1333MHz FSB
1000 applications, and 20 million entitlements.
Disk Partitioning
Configure the minimum swap size relative to system memory size.
Memory Swap Size

Memory < 2 GB Min. Swap = 3 GB
Memory 2 GB -16 GB Min Swap = Memory Size
Memory >16 GB Min Swap = 16 GB
Operating system partition: 50 GB minimum, 100 GB recommended (database not included)
Required Software
l Java: AdoptOpenJDK 1.8
AFX Port Requirements

AFX port usage is listed as follows:
Port Usage
JAVA RMI port used for retrieving JVM utilization information.
1099
Used by AFX, ActiveMQ, and MMC.
AFX management JMX port
1199
Listening port for exclusive use by AFX
Communication between ESB and AFX Management
7777
8089 The default port for RESTful WebService connectors for receiving asynchronous callback
120 Chapter 8: Access Fulfillment Express (AFX) Installation

Port Usage
messages. This port is used by endpoints which process AFX requests asynchronously
to respond back to AFX after the request has been processed. The response indicates if
the request was successfully processed.

Default Administrative Console port
8161
Used by AFX and ActiveMQ.
Required for all deployment models where AFX and remote agents are used
8444
Used by AFX and RSA Identity Governance and Lifecycle
AFX management port
8585
ActiveMQ JMS port
61616
Nproc Limits for Oracle User (Downloaded Server or Remote Machine)

Before installing AFX, update /etc/security/limits.conf as the root user with the following values:
oracle soft nproc 16384

oracle hard nproc 16384
Note: You must log in as the root account to ensure that the proper permissions are granted. This procedure
may not work using any other account.
Install AFX
RSA Identity Governance and Lifecycle v7.x must be installed before you install AFX v7.x.
This section describes how to install AFX. RSA Identity Governance and Lifecycle auto-generates an AFX server
configuration named “AFX Server" where RSA Identity Governance and Lifecycle is installed. There are two
sequential phases in the AFX installation process:
1. Installing the AFX Server on an appliance or a Software Bundle server that has RSA Identity Governance
and Lifecycle installed on it, or installing it on a server that does not have RSA Identity Governance and
Lifecycle installed on it. This latter scenario is typically referred to as a "remote AFX installation." It is
applicable to AFX deployment when RSA Identity Governance and Lifecycle is installed on the WebSphere
or WebLogic platforms or when you want to install AFX on a host where RSA Identity Governance and
Lifecycle is not installed.
See the topic relevant to your installation scenario and complete the procedure in the topic:
l Install the AFX Server on an Appliance or a Software Bundle Server Using the Installation Script
l Install an Additional AFX Server Instance on a Non-AFX-Host
2. Installing the AFX connector packages for the AFX Server. See Install the AFX Connector Packages.

Install the AFX Server on an Appliance or a Software Bundle Server Using

the Installation Script
This section describes how to run the installation script to install the AFX Server on an RSA appliance or on a
Software Bundle server where RSA Identity Governance and Lifecycle is installed.
Procedure
1. Log on to the appliance or server as the root user.
2. Run the AFX installation script:
cd <aveksa-staging-directory>/deploy/AFX-scripts/
./installAFX.sh -q
The installation script runs silently and does the following:

l Installs AFX Server files to $AVEKSA_HOME/AFX. By default, this is /home/oracle/AFX.
l Configures server SSL certificates.
l Registers “afx_server” service.
l Configures profiles for AVEKSA_OWNER and root users for initializing the AFX Server
environment.
Installation results for the AFX Server are written in the following log file on the installation host:
/tmp/afx-install.log
3. If you are logged in as root, log out and log in to the installation host as the 'AVEKSA_OWNER' user.
4. Start the AFX Server using the “afx” script located in the top level AFX installation directory. For example,
if AFX is installed in /home/oracle/AFX, enter:
/home/oracle/AFX/afx start
Next step
Install the AFX connector packages for this AFX release version. See Install the AFX Connector Packages.
Install the AFX Server from a Downloaded Local AFX Server

This section describes how to install the AFX Server on WebLogic or WebSphere or a remote AFX deployment on
an RSA Identity Governance and Lifecycle host where you want to install the local server from a downloaded local
AFX Server archive.
Procedure
1. Log on to RSA Identity Governance and Lifecycle.
2. Click AFX > Servers > AFX Server.

3. If required, update the Default Truststore Password. You must update it if you have changed the
password for the default JDK truststore (for example, JAVA_HOME/jre/lib/security/cacerts) on the AFX
Server host.
4. Select Download Server Archive to download the local AFX Server archive. See Download an AFX Server
Archive.
5. Install a new AFX Server or update it on this host. See Install
a New AFX Server, Install an AFX Server Service, or Update an AFX Server Installation for instructions.
6. Start the AFX server as described in Start the AFX Server.
7. Install the AFX Connector packages for this AFX version. See Install the AFX Connector Packages.
Install an Additional New AFX Server Instance on a Non-RSA Identity

Governance and Lifecycle Host
This section describes how to install AFX on a different server other than where RSA Identity Governance and
Lifecycle is installed. This scenario applies to WildFly, WebLogic, and WebSphere installations.
Procedure
1. Log in to RSA Identity Governance and Lifecycle.
2. Click AFX > Servers.
3. Create an AFX server configuration for the server instance you want to install on another host. See
"Creating AFX Servers" in Help for more information.
4. Select the AFX Server configuration that you just created and click Download Server Archive to download
the remote AFX server archive. See Download an AFX Server Archive.
5. See Install the AFX Server Using an Archive Downloaded from RSA Governance and Lifecycle to install a
new AFX server or update it on the remote machine.
6. Install the AFX Connector packages for this AFX release version. See Install the AFX Connector Packages.
Install the AFX Server Using an Archive Downloaded from RSA Identity
Governance and Lifecycle
This section describes how to perform the following tasks after you copy and download the AFX Server archive
from RSA Identity Governance and Lifecycle:
l Install a new AFX Server.

l Install an AFX Server service.
l Update an AFX Server.
Install a New AFX Server
This section describes how to install a new server from an AFX Server archive.
Procedure
1. Create an unprivileged account (for example, afxuser) on the host where you plan to run the AFX Server.
For example:
a. Log in as root user.
Note: You must log in as the root account to ensure that the proper permissions are granted.
This procedure may not work using any other account.

b. Create the user:
useradd afxuser -G users -d /home/afxuser
c. Create a home directory for the user:
mkdir /home/afxuser
d. Change the owner for the home directory:
chown afxuser:users /home/afxuser
This account is referred to as the “afx account” with the name “afxuser” throughout the remainder of
this procedure.
2. For the “afx account,” export JAVA_HOME and put $JAVA_HOME/bin in the PATH. JAVA_HOME must
point to a JAVA 1.8 installation.
3. Connect to the AFX Server machine using the “afx account.”
4. Copy the AFX Server archive downloaded from RSA Identity Governance and Lifecycle to the “afx
account” home directory on the AFX Server machine (for example, /home/afxuser).
5. Go to the “afx account” home directory and expand the AFX Server archive. For example:
cd /home/afxuser
unzip AFXServer.zip
An AFX directory is created in the “afx account” home directory (for example, /home/afxuser/AFX)
containing the server files.
6. Change to the AFX directory and execute the setPerms.sh script located in AFX/bin to set file
permissions. For example:
cd /home/afxuser/AFX
sh bin/setPerms.sh
7. Follow the steps in “Install an AFX Server Service” below to install the AFX Server service.
8. Start the AFX Server as described in Start the AFX Server.
Install an AFX Server Service
The AFX Server service is optional but it is highly recommended to ensure that when your AFX Server host is
restarted, the AFX Server instance is properly shutdown and started.
This procedures applies only when AFX and RSA Identity Governance and Lifecycle are installed on different
hosts. It is required for WebSphere and WebLogic installations.
Procedure
1. Connect to the AFX Server host as root user.
2. Create a link to the AFX startup script located in <path-to-AFX>/bin:

ln -s <path-to-AFX>/bin/afx_server /etc/init.d/afx_server
For example:
ln -s /home/afxuser/AFX/bin/afx_server /etc/init.d/afx_server
3. For SLES 12 only, as root, use the following command to copy necessary files:
cp -as path-to-AFX/bin/systemd/system /etc/systemd/system
cp -as path-to-AFX/bin/systemd/legacy-actions
/usr/lib/initscripts/legacy-actions
4. Add the service and enable it using the chkconfig utility:
chkconfig --add afx_server
chkconfig afx_server on
chkconfig --list afx_server
Update an AFX Server Installation
This section describes how to update an AFX Server installation with the archive in a scenario where you are
required to re-install your AFX Server.
Procedure
1. Connect to the AFX Server host using the “afx account.”
2. Stop the AFX Server as described in Stop the AFX Server.
3. Change the directory to the “afx account” home directory and rename the AFX folder to AFX-backup, for
example:
cd /home/afxuser
mv AFX AFX-backup
4. Copy the AFX Server archive that was downloaded from RSA Identity Governance and Lifecycle to the “afx
account” home directory on the AFX Server machine (/home/afxuser for example).
5. Change directory to the “afx account” home directory and expand the AFX Server archive. For example:
cd /home/afxuser
unzip AFXServer.zip
The “afx account” home directory (/home/afxuser/AFX for example) containing the server files now
contains an AFX directory.
6. Change to the AFX directory and execute the setPerms.sh script located in AFX/bin to set file
permissions. For example:
cd /home/afxuser/AFX
sh bin/setPerms.sh

7. Restore the ActiveMQ data directory (and its contents) from the prior installation backup to the new AFX
installation. Type:
cp -rfp <path-to-AFX-backup>/activemq/data <path-to-AFX>/activemq
where
l <path-to-AFX-backup> is the location of the backup
l <path-to-AFX> is the location of the new installation
For example:
cp –rfp /home/afxuser/AFX-backup/activemq/data
/home/afxuser/AFX/activemq
8. Start the AFX Server as described in Start the AFX Server.
Install the AFX Connector Packages

The connector packages include the connectors that fulfill changes in data endpoints.
Before You Begin

Download the AFX-<product-version>-Standard-Connectors.zip file for this RSA Identity Governance and
Lifecycle release from from RSA Link at https://community.rsa.com/community/products/governance-and-
lifecycle to a host that you can access with RSA Identity Governance and Lifecycle using a web browser.
Procedure
1. Log on to RSA Identity Governance and Lifecycle.
2. Select AFX > Import.
3. Browse to the AFX-<product-version>-Standard-Connectors.zip file.
4. Select Next.
5. Check the Select all items box to select all connector templates listed for import.
6. Select Import to load all standard connector template packages for this released version into RSA Identity
Governance and Lifecycle.
7. If you are licensed for one or more AFX Premium Connectors, repeat steps 1 through 5 for AFX-
<product-version>-Premium-Connectors.zip (also located in the packages directory for RSA Identity
Governance and Lifecycle v6.9.x and later).
Note: After you have imported all connector packages, any previously imported connectors and templates are
updated to include the latest enhancements. Those enhancements include new capabilities and settings, fixes
for known issues, and any changes to ensure compatibility with AFX Server v7.x.
Download an AFX Server Archive

For any non-RSA server on which you want install an AFX Server instance, you must first download an archive of
an AFX Server that you want to install.
Procedure
2. Select AFX > Servers.

3. From the list of AFX Server configurations, select the server that you want to download.
4. From the AFX Server configuration detail page, click Download Server Archive.
Note: It may take several minutes for the system to generate the AFX Server archive for download.
5. Specify the download location when prompted by the browser and save the AFX Server archive.
6. Install the archive. See Install the AFX Server Using an Archive Downloaded from RSA.
Start the AFX Server

Procedure
1. Connect to the AFX server host using the “afx account.”
2. Start AFX by using the “afx” admin script located in the top level AFX installation directory:
<path-to-AFX>/afx start
Example 1: /home/afxuser/AFX/afx start
Example 2: /home/oracle/AFX/afx start
For SLES 12
Use systemctl to start AFX:
systemctl start afx_server
Stop the AFX Server

Procedure
1. Connect to the AFX server host using the “afx account.”
2. Stop AFX by using the “afx” admin script located in the top level AFX installation directory:
<path-to-AFX>/afx stop
Example 1: /home/afxuser/AFX/afx stop
Example 2: /home/oracle/AFX/afx stop
For SLES 12
Use systemctl to stop AFX:
systemctl stop afx_server
Update ActiveMQ Settings
To configure memory management in ActiveMQ to handle bulk change request items, you may need to modify
the following ActiveMQ settings.
1. The queue can handle messages for a change request with about 500 change request items for an
AFX connector. To handle a larger number of items than this default, update the settings as follows.

a. Edit AFX\activemq\conf\activemq.xml.
b. Find the policyEntry tag and modify the memoryLimit attribute value based on the
requirement, as shown below, then save the changes.
<policyEntry queue=">" producerFlowControl="true"

memoryLimit="5mb">
2. The queue can handle approximately 50 AFX connectors for provisioning the change request items in
parallel with the default settings. To configure a larger number of connectors than default allows, based
on the requirement modify memoryUsage value accordingly.
Example:
Memory usage for an AFX connector needs approximately 5 MB. 5MB multiplied by 50 connectors is a
total of 250 MB, which is the default.
The memory usage is calculated based on the memoryLimit values in point 1.
a. Edit AFX\activemq\conf\activemq.xml.
b. Find the memoryUsage tag and modify the limit attribute value based on the requirement.
<memoryUsage>
<memoryUsage limit="256 mb"/>
</memoryUsage
c. Find the tempUsage tag and modify the limit attribute value same as memoryUsage value.
<tempUsage>
<tempUsage limit="256 mb"/>
</tempUsage>
d. Find the storeUsage tag and modify the limit based on changes of memoryUsage value.
<storeUsage>
<storeUsage limit="1 gb"/>
</storeUsage>
e. Save changes.
3. Based on the requirements and memory configuration changes, the ActiveMQ heap size must be
updated. The recommended heap size is between 2 and 4 GB.
a. Edit the AFX/bin/afx.sh script.
b. Update the ACTIVEMQ_OPTS Xms and Xmx values.
c. Edit the AFX/activemq/bin/activemq.sh script.
d. Update the ACTIVEMQ_OPTS Xms and Xmx values.

Appendix A: Security and Authentication Management

(RSA Appliance and Software Bundle)
Working with Keystores and Certificates
SSL is used to secure communication between RSA Identity Governance and Lifecycle and clients such as a
collector’s back-end server, AFX server, RSA agent, or a browser. SSL uses certificates which are stored in a
keystore repository. RSA Identity Governance and Lifecycle provides separate keystores for HTTPS
communications:
Port 8443 — aveksa.keystore
Port 8444 — server.keystore
By default, RSA Identity Governance and Lifecycle uses a self-signed certificate, which a user can accept when
logging in to RSA Identity Governance and Lifecycle. This server certificate is used to authenticate the identity of
the RSA Identity Governance and Lifecycle server.
To enable the secure connection, RSA Identity Governance and Lifecycle requires knowledge of the clients’
public certificates, and the clients require the RSA Identity Governance and Lifecycle server’s public certificate
to identify each other.
RSA Identity Governance and Lifecycle also uses a truststore to validate the authenticity of certificates by a CA.
RSA Identity Governance and Lifecycle uses the OpenJDK as the truststore containing the certificates of all the
well- known CAs.
Become familiar with the following terms that are referenced throughout the remainder of the discussion about
certificates:
l RSA Identity Governance and Lifecycle Server Certificate — Identifies the RSA Identity Governance and
Lifecycle's server.
l Client Certificate — A public certificate that identifies a client to which RSA Identity Governance and
Lifecycle establishes a secure connection.
l Trusted Authority Certificate — A root or intermediate certificate that is trusted and can be used when
validating a signed certificate.
Default RSA Identity Governance and Lifecycle keystores, passwords, and locations described in the following
sections:
l aveksa.keystore — The aveksa.keystore file contains the self-signed certificates that identify the RSA
Identity Governance and Lifecycle application server when it communicates with a browser via HTTPS.
This default server certificate is created with keysize = 2048, validity = 18000 days, and ALG = RSA.
For upgrades, use the existing keystore.
The keystore is in: /home/oracle/keystore/aveksa.keystore
The password is: Av3k5a15num83r0n3
You can use this keystore to configure the default HTTPS access on port 8443. You can modify this
Appendix A: Security and Authentication Management (RSA Appliance and Software Bundle) 129
keystore to meet the security requirements of the default HTTPS access to RSA Identity Governance and
Lifecycle.
l server.keystore — The server.keystore file secures communication between agents and RSA Identity
Governance and Lifecycle. It contains a signed server certificate and the trusted certificates used to sign
the server certificate. This default certificate is created with keysize = 2048, validity = 18000 days, and
ALG = RSA. The keystore is in: /home/oracle/keystore/server.keystore. The password is
Av3k5a15num83r0n3
The server.keystore is required for secure SSL port 8444 and used for communicating with remote
agents. You cannot modify this keystore.
l cacerts — The default truststore can be one of the following:

l Custom truststore which is assigned to the 'javax.net.ssl.trustStore' system property in JAVA_
OPTS.
The password is: changeit

Note: The password may be different for your custom truststore.
l client.keystore — The client.keystore file is created and used by a RSA Identity Governance and Lifecycle
remote agent.
This keystore is downloaded with the remote agent software from the user interface when a remote
agent is created or edited. For more information, see "Working with Agents" in the Help.
The password is: Av3k5a15num83r0n3
Note: Unless specified otherwise, all of the command examples in this section use the default passwords.
Keytool
Keytool is a certificate management utility. It is used to manage RSA Identity Governance and Lifecycle
certificates within the keystore that are referenced in this section. This keytool command is in the JAVA_HOME
directory.
You use Keytool to create a keystore file and manage the certificates in the keystore. The keytool command uses
an alias to reference the certificates. The alias is a simple well-known name associated with a certificate in the
file. When you use keytool, log in as the owner of the files you want to work on. For example, log in as root to
work with the cacerts file or as oracle to work with the aveksa keystore files.
For more information about the keytool command, see the OpenJDK documentation.
Note: Always back up a keystore or truststore before adding certificate information.
Ciphers
The RSA Identity Governance and Lifecycle appliance is configured with two ciphers for SSL:
l TLS_RSA_WITH_AES_128_CBC_SHA
l TLS_RSA_WITH_AES_256_CBC_SHA
130 Appendix A: Security and Authentication Management (RSA Appliance and Software Bundle)
You can edit the/home/oracle/wildfly/standalone/configuration/aveksa-standalone-full.xml file to remove

ciphers or add ciphers that your corporate infrastructure requires.
Managing the Keystore
This section describes how to list certificates in your keystore, change default keystore and truststore
passwords, and restore SSL server or agent certificates after an upgrade.
List Your Certificates in the Keystore

Procedure
keytool -list -storepass <Keystore Password> -keystore <Keystore File>
For example:
keytool -list -storepass Av3k5a15num83r0n3 -keystore server.keystore
Change the Default Aveksa Keystore Password

By default, RSA Identity Governance and Lifecycle has protected the keystore file with passwords. You can only
change the password for the aveksa.keystore used for default HTTPS access.
l The default install password is: Av3k5a15num83r0n3
The WildFly application server on which RSA Identity Governance and Lifecycle runs requires that the
keystore password and the generated server key (certificate) password are identical. If you want a
keystore with a different password, a new keystore file must be created with the new password. You
must also generate a new server certificate with the new password and re-import any additional
certificates. Also, the aveksa-standalone-full.xml file within WildFly that configures the SSL ports must
be updated with the new password information.
Required steps:
a. Generate a new keystore and server certificate with your desired password.
b. Import any other certificates you require into the new keystore.
c. Back up the current keystore.
d. Copy your new keystore to the aveksa.keystore.
e. Edit the aveksa-standalone-full.xml file with new password.
l The RSA Identity Governance and Lifecycle keystore location: /home/oracle/keystore/aveksa.keystore
Change to this directory to perform the tasks described below.
Procedure
keytool -genkeypair -keysize <keysize> -validity <#days> -alias <server-
cert-alias> -dname <domain-name> -keyalg <key algorithm> -file <Server_
cert_file> - keypass <Your Password> -storepass <Your Password> -keystore
<Keystore File>
For example:
keytool -genkeypair -keysize 2048 -validity 18000 -alias mycorpServer -
dname "CN=acm-
server.mycorp.com,OU=Aveksa,O=MyCorp,L=Waltham,S=Massachusetts,C=US" -
keyalg RSA-file server.cer -keypass new1Pass -storepass new1Pass -keystore
newPass.keystore
A new keystore file called newPass.keystore is created with an RSA Identity Governance and Lifecycle server
certificate with an alias of mycorpServer. The certificate is saved in the server.cer file.
Note: If you had previously created and signed your server certificate you will need to repeat the process of
generating a certificate signing request and importing the signed certificate. See Using a Signed Certificate for
HTTP Access to RSA Identity Governance and Lifecycle for more information
Import other certificates:

If your system requires any other client certificates import them into the new keystore file. (newPass.keystore
for example).
See Import a Trusted Certificate for more information.
Backup the current keystore:

mv aveksa.keystore aveksa.keystore.backup
Copy your new keystore to the aveksa.keystore:

cp newPass.keystore aveksa.keystore
Edit the WildFly aveksa-standalone-full.xml:

The aveksa-standalone-full.xml file is used to configure the secure 8443 HTTP port. It requires information
about the keystore and the keystore password. The file contains entries for the keystorePass and truststorePass.
Update all instances of these entries with your password for the new keystore.
1. Go to /home/oracle/wildfly/standalone/configuration.
2. Edit the aveksa-standalone-full.xml file for connection port 8443.
3. Restart RSA Identity Governance and Lifecycle.
acm restart
Change the Truststore Password

The JDK truststore’s default password is “changeit.” The truststore is located in the lib/security/ directory of
the Java jre.
File: $JAVA_HOME/jre/lib/security/cacerts (for example: /etc/alternatives/java_sdk_

1.7.0/jre/lib/security/cacerts)
Procedure
1. Go to the jre/lib/security directory.
2. Run this command:
keytool -storepasswd -new <mynewPassWord> -keystore cacerts -

storepass changeit
acm restart
Back Up and Restore Default HTTPS Certificates

You can back up the certificates in aveksa.keystore before an upgrade and restore them after the upgrade.
To back up certificates:
Back up the following directories from your current installation to a location where they can be retrieved for
restoration after the upgrade:
RSA Identity Governance and Lifecycle (Aveksa Compliance Manager) version 4.x, 5.0.x, 5.1.x:
/home/oracle/wildfly-<wildfly-
version>/server/default/deploy/aveksa.ear/aveksa.war/WEB-INF/certificates
RSA Identity Governance and Lifecycle (Aveksa Platform) version 5.5 or 6.x
To restore certificates:
1. Shut down Aveksa services as described in Stopping RSA Identity Governance and Lifecycle Services.
2. From the backed up directories from the previous installation, copy certificate keystore files to the deploy
directory.
l For upgrades from any pre-v5.5 version:
Copy the serverui.keystore file to the following file:
/home/oracle/keystore/aveksa.keystore
l For v5.5 or 6.x upgrades:
Copy the aveksa.keystore and client.keystore files to the following directory:
/home/oracle/keystore
3. Start Aveksa services as described in Starting RSA Identity Governance and Lifecycle Services.
If you do not have the keystore files but you do have a Backup<aveksa-version>.tar file created with the
acm_backup.sh script, you can find those files in the following directories in Backup<aveksa-
version>.tar:
l RSA Identity Governance and Lifecycle version 4.x, 5.0.x, 5.1.x:
version>/server/default/deploy/aveksa.ear/aveksa.war/WEB-
INF/certificates
l RSA Identity Governance and Lifecycle version 5.5 or 6.x:
version>/server/default/deploy/keystore
Migrating Certificates to SHA-256
RSA Identity Governance and Lifecycle contains certificates that allow you to secure communication with AFX
servers, remote agents, web browsers and web services using Secure Sockets Layer (SSL). RSA Identity
Governance and Lifecycle signs all new certificates using the SHA-256 algorithm. Your existing server and
client certificates are not affected if you have upgraded from an earlier product version, but RSA recommends
that you migrate your server certificate and your AFX and remote agent certificates to SHA-256 after you have
upgraded.
Note: To enable WebLogic to use certificates signed using SHA-256, you must enable JSSE on the WebLogic
server.
Migrate the RSA Identity Governance and Lifecycle Server Certificate to

SHA-256
Procedure
1. Click the Admin menu and select System > Security.
2. Click Change Certificate Store.
3. In the Change Certificate Store window, click OK.
4. Click Download and save the server.keystore file on your computer.
5. Log in to the installation machine as the ‘admin’ user and enter the following command:
sudo service aveksa_server stop
6. Copy the server.keystore file to <AVEKSA_HOME>/keystore.

sudo service aveksa_server start
Configure SSL for a Collector Endpoint
You can use SSL to secure the connection between RSA Identity Governance and Lifecycle and a collector
endpoint by importing the endpoint server certificate into the truststore on the RSA Identity Governance and
Lifecycle application server.
Note: This procedure describes how to directly update the cacerts truststore file using the keytool. This is only
one method to update certificate truststore information. Your organization may use other tools or methods for
updating truststores.
Before you begin
Obtain the server certificate for your endpoint, such as Active Directory or Novell. Consult your administrator for
this information.
Procedure
1. Log in as root, and go to the truststore directory. The location of the truststore varies based on your
environment.
l In a WildFly Application Server environment, import the certificate to $JAVA_

HOME\lib\security\cacerts.
If the server uses the system property javax.net.ssl.trustStore to override the default settings in
either standalone.xml or domain.xml, the certificate should be added to the custom truststore.
l In a WebLogic Application Server environment:

l If the truststore is specified by the -Dweblogic.security.SSL.trustedCAkeystore
command-line argument, import the certificate into this truststore.
l If the truststore is specified in the configuration, import the certificate into the custom
truststore. In a typical RSA Identity Governance and Lifecycle deployment,
/home/oracle/server.keystore is used as the custom truststore.
l In a WebSphere Application Server environment, obtain the SSL configuration settings for the
selected scope, either the node or the server. Import the certificate to the selected
SSL configuration.
If the truststore is defined using the custom property on the JVM, the custom truststore is used
instead of the SSL Configuration Repositories settings in the WebSphere administration console.
To determine if the configuration uses custom properties, log on to the WebSphere console and
select Servers > Application Servers > server_name > Process Definition > Java Virtual
Machine > Custom Properties, and see the following truststore javax
properties: javax.net.ssl.trustStore, javax.net.ssl.trustStorePassword, and
javax.net.ssl.trustStoreType.
2. Use the following command to back up your truststore:
3. Import the trusted authority certificate using the keytool as follows:

ACME_Root.cer -storepass changeit -keystore cacerts
After import, the following message is displayed:
4. Restart RSA Identity Governance and Lifecycle using the following command:
acm restart
Establishing a Secure LDAP/AD Connection for a Data Collector
The RSA Identity Governance and Lifecycle server can establish secure communication via SSL. To establish this
communication, the server must contain the public certificates used to identify the systems to which it connects
via SSL. The other systems must have trust in the RSA Identity Governance and Lifecycle server via a server
public certificate.
This process involves adding a public certificate to the RSA Identity Governance and Lifecycle server keystore as
well as adding the RSA Identity Governance and Lifecycle server's public certificate to the remote
system/application’s keystore. Also, if the public certificates of the connecting systems are signed, you must
import the certification authority's root CA certificate file as well.
Note: As of RSA Identity Governance and Lifecycle version 7.1.1, the JRE has been upgraded to Java 8. By
default, Java 8 enforces endpoint identification on LDAPS connections to improve the robustness of the
connections. After upgrading, Active Directory collectors that use SSL that were previously able to connect
might be unable to connect. View the aveksaServer.log for details about connection failures. If this occurs,
ensure that the certificate of the host configured in the collector settings has the correct subject alternative
name attributes available that match the hostname.
Export the Application Server's Public Certificate

The application server's public certificate may be needed for secure SSL communication.
Procedure
keytool -export -alias <Certificate alias> -file <Server_cert_file> -

storepass <Keystore Password> -keystore <Keystore File>
For example:
keytool -export -alias server -storepass Av3k5a15num83r0n3 -file

~/server01.cer -keystore aveksa.keystore
This exports the server certificate into a file called server01.cer. This file can then be copied to the
necessary locations required for the given LDAP/AD system.
acm restart
Import LDAP/AD system Certificates into the Truststore

The application server may require client certificate information for secure SSL communication to a client. For
instructions on importing the required certificates, see Step 3: Import a Trusted Certificate on page 64.
Appendix B: Troubleshooting
l Troubleshooting an RSA Appliance or Software Bundle

l Troubleshooting a WebSphere Installation
l Troubleshooting a WebLogic Installation
Troubleshooting an RSA Appliance or Software Bundle
l Overview
l Installation
l Start Up
l Runtime
l Certificate and Keystore Management
Overview
This chapter describes potential problems you may encounter with deploying, starting, and running RSA
Identity Governance and Lifecycle on WildFly. The installation process produces log files that can be examined
for problems during the installation process:
l The /tmp/aveksa-install.log file is generated by the RSA Identity Governance and Lifecycle installation
l The /tmp/aveksa/oracle.log file is associated with the Oracle installation.
The Wildfly server and the RSA Identity Governance and Lifecycle application both provide log files that can help
you pinpoint configuration or runtime problems.
l The /home/oracle/wildfly/standalone/log/server.log file is the Wildfly runtime log file.
The following RSA Identity Governance and Lifecycle log files are located in WildFly in the
/home/oracle/wildfly/standalone/log directory:
l The aveksaServerInfo.log file provides configuration information about the RSA Identity Governance and
Lifecycle application server configuration. This includes application version information, Java JVM
settings, database configuration, and application module configurations.
l The aveksaServer.log file provides information on the RSA Identity Governance and Lifecycleserver
execution. For information on managing aveksaServer.log views in the RSA Identity Governance and
Lifecycle user interface, see the Help topic, "Application Log Administration."
l The create.log file provides information about interactions involved with deploying and/or migrating
schema changes to the database. Problems with the database deployment might cause problems
initializing the RSA Identity Governance and Lifecycle application. This log file might be in a different
location as it is created in the directory where the createSchema is run.
l patch.log file provides information about script-driven hot fix installations. This file is generated when a
patch is applied.
l The reporting-user-synonyms.log file provides information about updates to user synonyms in the
avdwdb data source.

l The public-schema-synonyms.log file provides information about updates to user synonyms in the
acmdb data source. This file is generated only when synonyms are updated.
The migrate.log file is located in the /home/oracle/database/log directory:
l The migrate.log file provides information about database migration phases.
Installation
Problem: You see the following output from the installer.
Installing Oracle...
Expand the Oracle Installers...
Check the System Configuration...
Install Oracle Grid Software...
Step failed! See /tmp/aveksa-install.log for more information.
The /tmp/aveksa-install.log shows:
INFO: *********************************************
INFO: Network Time Protocol (NTP): This task verifies cluster time
synchronization on clusters that use Network Time Protocol (NTP).
INFO: Severity:CRITICAL
INFO: OverallStatus:VERIFICATION_FAILED
INFO:
Reason: The Oracle process determines whether an NTP service is configured and running. This problem can
occur if the system is not connected to the internet.
Solution: Start the NTP deamon or follow these steps to disable and, as root, remove the ntpd files and restart
your installation:
1. Run these commands:
/sbin/service ntpd stop
chkconfig ntpd off
rm /etc/ntp.conf or, mv /etc/ntp.conf to /etc/ntp.conf.org
2. Remove the /var/run/ntpd.pid file if it exists.

3. Restart the installation.
138 Appendix B: Troubleshooting

Start Up
If you encounter problems with starting RSA Identity Governance and Lifecycle after you have completed post-
deployment tasks, examine the aveksaServer.log file or the WildFly server.log file for problem indicators.
Problem: The RSA Identity Governance and Lifecycle displays the following error message when you attempt to
access the application:
Unable to initialize security model. Security application not created.
The aveksa security application must be initialized first by the System

Operations Node(SON).
See documentation regarding server nodes and deployment.
Reason: The node that was started is not the System Operations Node (SON). The SON performs the
initialization of the security model. The SON must be started first. This could be caused by the following
circumstances:
l The SON in a clustered environment was not started and used to initialize the system before starting
other nodes.
l A data dump was moved from one system to another (a development system to a production system for
example) where the originating system is still registered as the SON. The system stores a list of
registered servers in the database and their role. The dump will contain the information of the server
that was the SON when the dump was taken.
Solution: Examine the aveksaServer.log file to determine the role of this node. Look for a line similar to the
following:
08:50:48,555 INFO [ServerNodeServiceProvider] Node Name : <Machine Name>

has been updated to Role General_Node
Do the following as applicable:
l If the application is in a cluster, start the SON first, and then start any other general nodes.
l If you have imported a new data dump, it is possible that an older machine is listed as the SON. In this
case, the server nodes table can be cleaned and the server can be restarted. The system will then self
register as the SON. You can determine the list of registered servers, status, and roles by querying the
T_SERVER_NODES table.
To list the known server(s), execute the following sql on the avuser:
select NODE_NAME, HOST_NAME, NODE_ROLE, NODE_STATUS from T_SERVER_NODES;
To Clear out the server node table, execute the following sql on the avuser schema:
Delete * from T_SERVER_NODES;
Commit the changes, and then restart the server.
Problem: The migration fails when migrating the database when upgrading to a newer version of the RSA
Identity Governance and Lifecycle application. The following error messages appear in the user interface or in
the migrate.log file.:

java.sql.SQLException: ORA-14452: attempt to create, alter or drop an

index on temporary table already in use
or
Errors Detected:
ORA-14452
Examine the log file: migrate.log for more information. Consult the
installation guides if this is a known issue.
Reason: A table could not be modified during migration. This might be caused if a database session is holding
that table, possibly caused by another running node.
Solution: Verify that all nodes or other processes that may be accessing the schema are shutdown/stopped.
The following database query may provide information about what might be holding a session to the database
schema.
select machine, logon_time from v$session where username='AVUSER';
Ensure all instances of the the RSA Identity Governance and Lifecycle application have been stopped.
It is highly recommended that you repeat the migration. You can do this by simply modifying the
“productVersion” parameter in the database T_SYSTEM_SETTINGS table, setting it to the product version of the
version from which you are upgrading.
For example:
UPDATE T_SYSTEM_SETTINGS SET VALUE='6.0.2'
Where the value ='productVersion'
Commit the changes, restart the application server, and then perform the migration.
Problem: The RSA Identity Governance and Lifecycle application displays the following error message when you
attempt to access the application:
The character set for the database is configured to WE8MSWIN1252; however,

AL32UTF8 is the required database character set. Please consult the
Database Guide to create a database instance that meets the product
requirements and then restart the application.
The error message is also included in the aveksaServer.log file.
Reason: It is important that the database is configured to the correct character set that may be used within the
product. Failure to do so may result in corrupted data in those tables where non-conforming characters may be
written.
Solution: See the Database Guide for information on configuring a database instance. If you have data you wish
to preserve please back up your database, create a new database that is configured with the correct database
character set, and import your data dump into the database.
Runtime
If you encounter problems while RSA Identity Governance and Lifecycle is running, examine the

aveksaServer.log file for problem indicators.
Problem: RSA Identity Governance and Lifecycle logs the following error message:
HQ212051: Invalid concurrent session usage. Sessions are not supposed to

be used by more than one thread concurrently.: java.lang.Exception: trace
Reason: This is a known bug in WildFly. It causes no loss of functionality.
Solution: You can safely ignore this log message.
Certificate and Keystore Management

This section describes potential problems you may encounter with starting and running RSA Identity
Governance and Lifecycle on WildFly with regard to certificates and keystores.
Note: See RSA Identity Governance and Lifecycle Security and Authentication Management for information on
managing certificates.
Problem: After using certificates the RSA Identity Governance and Lifecycle server is unresponsive.
Cited in the WildFly Server log file: /home/oracle/wildfly/standalone/log/server.log.
06/08/2012 10:37:31.925 ERROR (http-0.0.0.0-8443-Acceptor-0)

[org.apache.tomcat.util.net.JIoEndpoint] Socket accept failed
java.net.SocketException: SSL handshake errorjavax.net.ssl.SSLException:
No available certificate or key corresponds to the SSL cipher suites which
are enabled.
at org.apache.tomcat.util.net.jsse.JSSESocketFactory.acceptSocket
(JSSESocketFactory.java:150
at org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run
(JIoEndpoint.java:309)
at java.lang.Thread.run(Thread.java:662)
Solution: The CN of the FQDN of the certificate may be incorrect. Delete the existing certificate and re-generate
a new server certificate.
Problem: Unable to login into RSA Identity Governance and Lifecycle with secure HTTPS. The server.log file
cites:
07/13/2012 16:22:11.516 INFO (main)

[org.apache.coyote.http11.Http11Protocol] Starting Coyote HTTP/1.1 on
http-0.0.0.0-8080
07/13/2012 16:22:11.557 ERROR (main)

[org.apache.coyote.http11.Http11Protocol] Error starting endpoint
java.io.IOException: Keystore was tampered with, or password was incorrect
at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:771)
Reason: The aveksa-standalone-full.xml file connection configuration has wrong keystore password.

Solution: Edit the aveksa-standalone-full.xml and correct the keystore information. See Change the Default
Aveksa Keystore Password for more information.
Problem: Unable to login into RSA Identity Governance and Lifecycle with secure HTTPS. The server.log file
cites:
2012-07-17 07:29:50,431 INFO [org.apache.coyote.http11.Http11Protocol]

Initializing Coyote HTTP/1.1 on http-0.0.0.0-8080
2012-07-17 07:29:50,560 ERROR [org.apache.coyote.http11.Http11Protocol]

Error initializing endpoint
java.io.IOException: Cannot recover key
at org.apache.tomcat.util.net.jsse.JSSESocketFactory.init
(JSSESocketFactory.java:394)
at org.apache.tomcat.util.net.jsse.JSSESocketFactory.createSocket
at org.apache.tomcat.util.net.JIoEndpoint.init(JIoEndpoint.java:497)
at org.apache.coyote.http11.Http11Protocol.init(Http11Protocol.java:176)
at org.apache.catalina.connector.Connector.initialize(Connector.java:1073)
at org.apache.catalina.core.StandardService.initialize
(StandardService.java:668)
Reason: The keystore password and server certificate passwords do not match.
Solution: Generate the keystore file with a server certificate with the same password. See Change the Default
Aveksa Keystore Password for more information.
Problem: LDAP Collection test fails with SSL. The aveksaServer.log file cites the following:
Collector test failed:
com.aveksa.server.runtime.ServerException: Test request failed with

response: com.aveksa.server.runtime.ServerException:
com.aveksa.common.ConnectException: Error in get connection to
UserDirectory. Caused by javax.naming.CommunicationException: simple bind
failed: 10.110.13.91:636 [Root exception is
javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find
valid certification path to requested target]. Caused by
javax.net.ssl.SSLHandshakeException:
valid certification path to requested target. Caused by


valid certification path to requested target. Caused by
valid certification path to requested target Caused By Stack
com.aveksa.common.ConnectException: Error in get connection to
UserDirectory at
com.aveksa.collector.accountdata.LdapAccountDataReaderConfig.connect
(LdapAccountDataReaderConfig.java:250) at
com.aveksa.collector.accountdata.LdapAccountDataReader$AccountDataDirector
yIterator.
Reason: ACM/SSL is not able to validate the certificate authority of the certificate from the LDAP or AD server.
The root or intermediate CA of the certificate of the AD/LDAP server is not added to the truststore referred by the
host.
Solution: The information about the CA of the certificate of the LDAP or AD directory server must be added to
the truststore. Add the root/intermediate certificates for the CA to the truststore. For more information, see Step
3: Import a Trusted Certificate on page 64.
To identify the truststore location referred by the host:
1. Add the following line to /home/oracle/wildfly-<wildflyversion>/bin/standalone.conf
JAVA_OPTS="$JAVA_OPTS -
Djavax.net.debug=ssl:session:sslctx:sessioncache:keymanager:trustmana
ger"
2. Use the following command to restart the server:
service aveksa_server restart
3. Perform the test collection and check the aveksaServer.log. Look for the log: 'trustStore is:'. The location
given in this log statement is the default truststore referred by your host.
4. Once the truststore is identified, add the trusted certificates to the truststore.
5. Remove the above added line from standalone.conf by commenting it out:
#JAVA_OPTS="$JAVA_OPTS -
Djavax.net.debug=ssl:session:sslctx:sessioncache:keymanager:trustmana
ger"
6. Use the following command to restart the server:
service aveksa_server restart
Problem: The following error is logged multiple times and fills up the log:
ERROR (http-0.0.0.0-8444-Acceptor-0)
[org.apache.tomcat.util.net.JIoEndpoint] Socket accept failed
java.net.SocketException: SSL handshake errorjavax.net.ssl.SSLException:

No available certificate or key corresponds to the SSL cipher suites which

are enabled.
at org.apache.tomcat.util.net.jsse.JSSESocketFactory.acceptSocket
at org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run
(JIoEndpoint.java:309)
at java.lang.Thread.run(Thread.java:662)
Reason: A certificate being used by the system was removed from the aveksa.keystore, usually as part of the
process for replacing a certifcate.
Solution: Restore the aveksa.kesytore from a backup, and begin the process of replacing the certifcate again.
For more information, see Using a Signed Certificate for HTTP Access to RSA Identity Governance and Lifecycle.

Troubleshooting a WebSphere Installation
l Overview
l Deployment
l Start Up
l Runtime
l Post-Deployment or Upgrade of RSA Identity Governance and Lifecycle
Overview
This chapter describes potential problems you may encounter with deploying, starting, and running RSA
Identity Governance and Lifecycle on WebSphere. The WebSphere server and the RSA Identity Governance and
Lifecycle application provide log files that can help you identify problems that may occur during configuration or
runtime.
The following directory includes the SystemErr.log and SystemOut.log files:
$WEBSPHERE_HOME/AppServer/profiles/AppSrv01/logs/server1
RSA Identity Governance and Lifecycle has several log files that are created in the deployed application directory
(ear) on WAS. Use your command line shell to determine the path to the ear. The path to the ear is similar to:
/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/installedApps/hostnameNode01Cell/aveksa.ear
Your path will vary based on your WebSphere install location, server name, hostname, node, and cell. This path
is referenced by EAR_PATH.
The following directory includes the aveksaServerInfo.log, aveksaServer.log, create.log, migrate.log, patch.log,
reporting-user-synonyms.log, and the public-schema-synonyms.log files:
$ EAR_PATH /aveksa.war/log
l The aveksaServerInfo.log file provides configuration information about the RSA Identity Governance and
l The aveksaServer.log file provides information on the RSA Identity Governance and Lifecycle server
execution.
avdwdb data source.
Deployment
Problem: Testing the JBDC data source connections fails, and the error message indicates a failure to locate the
ojdbc jar file.
Note: The version of the ojdbc jar file is the one specified when setting up Oracle JDBC Provider.
Solution: Make sure the DISTRIBUTION path specified for Oracle is correct. The path specification is case
sensitive.
Problem: Deployment fails or appears to hang after some period of time.
Reason: This may be due to out-of-memory errors during deployment.

Examine the SystemOut.log file for the server. Look for messages similar to the following:
8/14/13 14:35:59:509 EDT] 00000004 DefaultTokenP E HMGR0150E: An attempt to create a token to secure the High
Availability Manager connection failed. The exception is java.lang.OutOfMemoryError
at java.lang.Object.clone(Native Method)
Solution: Increase the memory for the Deployment manager (not the node on which the application runs) from
the WebSphere console:
1. Go to System Administration > Deployment Manager > Process definition.

2. Under Additional Properties, click Java Virtual Machine.
3. Enter 4096 in the Maximum Heap Size field.
4. Delete any java dump files created when the out-of-memory error occurred.
5. Delete all the Snap.* javacore.* heapdump.* files in the deployment manager directory.
6. Restart WebSphere server and redeploy the Aveksa EAR.
Start Up
If you encounter problems with starting RSA Identity Governance and Lifecycle after you have completed post-
deployment tasks, check the RSA Identity Governance and Lifecycle and WAS log files.
Problem: The migration fails when migrating the database during an upgrade to a newer version of the RSA
java.sql.SQLException: ORA-14452: attempt to create, alter or drop an

index on temporary table already in use
or
Errors Detected:
ORA-14452
Examine the log file: migrate.log for more information. Consult the
installation guides if this is a known issue.
Solution: Verify that all nodes or other processes that may be accessing the schema are shutdown/stopped. The
following database query may provide information about what might be holding a session to the database
schema.
Ensure all instances of the RSA Identity Governance and Lifecycle application have been stopped.
For example:

Problem: The RSA Identity Governance and Lifecycle displays the following error message when you attempt to
access the application:
Unable to initialize security model. Security application not created.
The aveksa security application must be initialized first by the System

Operations Node(SON).
See documentation regarding server nodes and deployment.
Reason: The node that was started is not the System Operations Node (SON). The SON performs the
initialization of the security model. The SON must be started first. This could be caused by the following
circumstances:
l The SON in a clustered environment was not started and used to initialize the system before starting
other nodes.
l A data dump was moved from one system to another (a development system to a production system for
example) where the originating system is still registered as the SON. The system stores a list of
registered servers and their roles in the database. The dump contains the information of the server that
was the SON when the dump was taken.
Solution: Examine the aveksaServer.log file to determine the role of this node. Look for a line similar to the
following:
08:50:48,555 INFO [ServerNodeServiceProvider] Node Name : <Machine Name> has been updated to
Role General_Node
Do the following as applicable:
l If the application is in a cluster, start the SON first, and then start any other general nodes.
l If you have imported a new data dump, it is possible that an older machine is listed as the SON. In this
case, the server nodes table can be cleaned and the server can be started. The system will then self
register as the SON. You can determine the list of registered servers, status, and roles by querying the
T_SERVER_NODES table.
To list the known server(s), execute the following sql on the avuser:
select NODE_NAME, HOST_NAME, NODE_ROLE, NODE_STATUS from T_SERVER_NODES;
To Clear out the server node table, execute the following sql on the avuser schema:
Delete * from T_SERVER_NODES;
Commit the changes, and then restart the server.
The character set for the database is configured to WE8MSWIN1252; however,

AL32UTF8 is the required database character set. Please consult the

Database Guide to create a database instance that meets the product

requirements and then restart the application.
written.
Problem: RSA Identity Governance and Lifecycle application displays the following error message when you
Unable to register service PersistenceService.

java.lang.ExceptionInInitializerError
The aveksaServer.log file lists this error:
09/27/2013 12:00:21.677 ERROR (server.startup : 0)

[com.aveksa.server.db.persistence.PersistenceServiceProvider]
initializeSessionFactory
java.lang.NoSuchMethodError: javax/persistence/OneToMany.orphanRemoval()Z
at org.hibernate.cfg.AnnotationBinder.processElementAnnotations
(AnnotationBinder.java:1912)
at org.hibernate.cfg.AnnotationBinder.processIdPropertiesIfNotAlready
(AnnotationBinder.java:796)
at org.hibernate.cfg.AnnotationBinder.bindClass(Annot . . . .)
Reason: On WebSphere 7.x and 8.0 you must associate a .jar file with the RSA Identity Governance and
Lifecycle application using the WebSphere shared library
Solution: Follow the instruction on configuring the shared library as described in Configure the RSA Identity
Governance and Lifecycle Shared Library.
Problem: RSA Identity Governance and Lifecycle application does not start. The SystemErr.log file contains an
error similar to the following:
[6/10/10 13:52:53:563 EDT] 00000030 SystemErr R Caused by:

javax.resource.spi.InvalidPropertyException: CWSJR1181E: The JMS
activation specification has invalid values - the reason(s) for failing to
validate the JMS activation specification are: [CWSJR1187E: The bus name
on a JMS activation specification must be given a value]
Reason: One of the activation specifications was created without the bus defined.

Solution: In the Admin Console, examine wpEventActSpec, wpServAutoActActSpec and wpUtilActSpecResource

> JMS > Activation Specifications.
1. Select the Activation Specification.

2. Examine the Bus Name field, and validate that wpBus is defined.
Problem: Login screen shows the following error:
Unable to get the <acmdb,avdb,avdwdb> data source. Verify the jdbc

datasource configuration for <acmdb,avdb,avdwdb> in the application
server.
Reason: The data source was configured incorrectly.
Solution: Check the following:
l In the WebSphere Admin console, validate the data source is configured with the correct JNDI name,
jdbc/avdb for avdb data source for example.
l Check that the custom property oracle9iLogTraceLevel for has no value set as described in Create the
JDBC Data Sources for data sources cited in aveksaServer.log file error messages like these:
Caused by:
java.lang.NoSuchMethodError:
oracle/jdbc/driver/OracleLog.setLogVolume(I)V at
com.ibm.ws.rsadapter.dbutils.impl.OracleUtilityImpl.setLogVolume
(OracleUtilityImpl.java:85)
or
06/01/2011 12:31:06.550 ERROR (server.startup : 0)

[com.aveksa.migration.jdbctool.CheckDatabase] Unable to get the acmdb
datasource
com.ibm.websphere.naming.CannotInstantiateObjectException: Exception
occurred while the JNDI NamingManager was processing a
javax.naming.Reference object. [Root exception is
com.ibm.websphere.naming.CannotInstantiateObjectException: Exception
occurred while the JNDI NamingManager was processing a
javax.naming.Reference object. [Root exception is
java.lang.reflect.InvocationTargetException]] at
com.ibm.ws.naming.util.Helpers.processSerializedObjectForLookupExt
(Helpers.java:1000)
Problem: Login screen displays an error similar to the following:
Initialization has failed!
AVUSER permission: ANALYZE ANY missing.
AVSDWUSER permission: CREATE PROCEDURE missing.

AVSDWUSER permission: CREATE SESSION missing.
Reason: The database users were not provided the required database privilege grants.
Solution: Provide the required privilege grants to the database users. See the Database Setup and Management
Guide for more information.
Problem: Application fails to start and log shows an error similar to the following:
java.lang.UnsupportedClassVersionError: JVMCFRE003 bad major version
Reason: The application server is configured to the wrong version of the Java SDK.
Solution: Set the Java SDK to the supported version.
1. Stop the server.

2. In the WebSphere console, click on Application Server.
3. Under the Server Infrastructure setting, click Java SDKs.
4. Change the Default SDK Version from 1.6* to 1.7*/1.8* (as applicable)
5. Restart the server.
Runtime
Problem: Change request workflow processes do not execute correctly according to the standard output log file,
which contains descriptions of connection timeout errors.
Reason: The connection pool count for the AVDB data source may need a higher value.
Solution: Increase the connection pool count by a system-appropriate value until the errors stop occurring.
Post-Deployment or Upgrade of RSA Identity Governance and Lifecycle

Problem: Cannot log into the RSA Identity Governance and Lifecycle application.
Reason: The database source may have been configured with the wrong user. For example, the "acmdb"
database source is configured with the "avuser" user. This may cause Creation or Migration SQL scripts to be
executed as the wrong user.
For example, if the "acmdb" data source is configured with the "avuser" user and not "acmdb," the end of the
migrate.log file will indicate that the avuser views have been dropped as indicated (v_*).
Solution: Examine the avdb, avdwdb and acmdb data sources configured on the application server. Validate the
correct user credentials are set, and then re-deploy the application.

Troubleshooting a WebLogic Installation
l Overview
l Deployment
l Start Up
l Runtime
l Post-Deployment or Upgrade of RSA Identity Governance and Lifecycle
Overview
This section describes potential problems you may encounter with deploying, starting, and running RSA
Identity Governance and Lifecycle on WebLogic. The WebLogic server and RSA Identity Governance and
Lifecycle application both provide log files that can help you pinpoint problems that may occur during
configuration or with RSA Identity Governance and Lifecycle at runtime. The WebLogic system log files can be
accessed from paths similar to the following:
$WEBLOGIC_HOME/user_projects/domains/<aveksaDomain>/servers/<Target Server>/logs
For example: /home/oracle/Oracle/Middleware/user_projects/domains/aveksadomain/servers

/AdminServer/logs/AdminServer.log
$WEBLOGIC_HOME/user_projects/domains/<aveksaDomain>/logs
The standard output from the startWeblogic.sh can provided additional troubleshooting information. RSA
Identity Governance and Lifecycle has several log files that are created in the deployed application directory
(ear) on WebLogic. Use your command line shell to determine the path to the ear. The path to the ear is similar
to:
$WEBLOGIC_HOME/user_projects/domains/aveksaDomain/servers/AdminServer/tmp/_WL_
user/aveksa/ldedze/aveksa.war/log
Your path will vary based on your WebLogic install location as well as your domain. This path is referenced by
EAR_PATH.
The following directory includes the aveksaServerInfo.log, aveksaServer.log, create.log, migrate.log, patch.log,
reporting-user-synonyms.log, and the public-schema-synonyms.log files:
$ EAR_PATH /aveksa.war/log
l The AveksaServerInfo.log file provides configuration information about the RSA Identity Governance and
l The aveksaServer.log file provides information on the RSA Identity Governance and Lifecycle server
execution.
l The create.log file provides information about interactions involved with deploying and/or migrating
schema changes to the database. Problems with the database deployment may cause problems
initializing the RSA Identity Governance and Lifecycle application.
l The migrate.log file provides information about database migration phases.
l The patch.log provides information about script-driven hot fix installations.

avdwdb data source.
l The public-schema-synonyms.log file provides information about updates to user synonyms in the
acmdb data source.
Deployment
Problem: The deployment fails. The following error appears the in the AdminServer.log file:
<Error> <HTTP> <BEA-101163> <Could not load user defined listener:

com.aveksa.gui.core.filters.SessionTimeoutListener
java.lang.ClassNotFoundException: com.aveksa.gui.core.filters.SessionTimeoutListener
at weblogic.utils.classloaders.GenericClassLoader.findLocalClass(GenericClassLoader.java:296)
at weblogic.utils.classloaders.GenericClassLoader.findClass(GenericClassLoader.java:269)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at weblogic.utils.classloaders.GenericClassLoader.loadClass(GenericClassLoader.java:177)
Truncated. see log file for complete stacktrace
Reason: On a Solaris box, class files are truncated because the ACM-WebLogic.tar file was extracted using the
Solaris version of tar.
Solution: Extract the ACM-Weblogic.tar file using a tar utility that handles long path names correctly, for
example gtar from gnu.
Problem: You encounter an error message similar to the following:
10 4:31:00 PM EDT> <Error> <Deployer> <BEA-149265> <Failure occurred in the execution of deployment
request with
04516440' for task '0'. Error is: 'weblogic.application.ModuleException: Exception preparing

module: EJBModule(war)
deploy EJB: ServerAutomatedActivityMDBean from wpServer.jar:
security principal, 'workpoint', chosen for the EJB 'ServerAutomatedActivityMDBean(Application:

aveksa, EJBComperver.jar)' is not a valid user principal in the current security realm.
Reason: The security realm user, workpoint, was not created.
Solution: Create the security realm user, workpoint, and continue with the deployment.
Problem: The standard output exhibits errors like the following:
The run-as security principal, 'workpoint', chosen for the EJB 'ServerAutomatedActivityMDBean
(Application: avekponent: wpServer.jar)' is not a valid user principal in the current security
realm. Please specify a valid user for the EJB to use.
weblogic.ejb.container.deployer.BeanInfoImpl.calculateRunAsPrincipal(BeanInfoImpl.java:1061)
weblogic.ejb.container.deployer.BeanInfoImpl.prepare(BeanInfoImpl.java:1007)

Reason: The workpoint user for the security realm was not created or misconfigured.
Solution: Create/edit the security realm user, workpoint, and then stop and restart the server.
Problem: Problems with workflow execution; workflow fails. Examine hte aveksaServer.log file. Check for the
following error messages:
java.lang.RuntimeException: Illegal TXN State: Attempt to start new transaction during rollback.
Txn count=1
Solution: Check the JTA transaction timeout setting (see Configure JTA Timeout Setting). If the setting is lower
than 120 seconds, set it to 120. If it is already set to 120 or higher, contact Tech Support.
Problem: Could not establish a connection because of java.lang.IllegalArgumentException: ONS configuration

failed
weblogic.jdbc.common.internal.DataSourceUtil.testConnection0 (DataSourceUtil.java:423)
weblogic.jdbc.common.internal.DataSourceUtil.access$000(DataSourceUtil.java:24)
Solution: Run the following command:
cd /home/oracle/Oracle/Middleware/Oracle_Home/user_projects/domains/base_
domain/bin
vi setDomainEnv.sh
For WebLogic Server versions 12.2.1.3.0 and above, disable the FAN setting by adding
-Doracle.jdbc.fanEnabled=false to the end of JAVA_OPTIONS.
Start Up
If you encounter problems with starting RSA Identity Governance and Lifecycle, you can check log files for
indications of where the problems occurred.
Log files can be accessed from paths similar to following:
$WEBLOGIC_HOME/user_projects/domains/<aveksaDomain>/servers/<Target Server>/logs
$WEBLOGIC_HOME/user_projects/domains/<aveksaDomain>/logs
The standard output from the startWeblogic.sh can provided additional information.
Problem: The migration fails when migrating the database when upgrading to a newer version of the RSA
java.sql.SQLException: ORA-14452: attempt to create, alter or drop an index on temporary table

already in use
or
Errors Detected:
ORA-14452
Examine the log file: migrate.log for more information. Consult the installation guides if this is
a known issue.

Solution: Verify that all nodes or other processes that may be accessing the schema are shutdown/stopped. The
following database query may provide information about what might be holding a session to the database
schema.
Ensure all instances of the RSA Identity Governance and Lifecycle application have been stopped.
For example:
The character set for the database is configured to WE8MSWIN1252; however, AL32UTF8 is the required
database character set. Please consult the Database Guide to create a database instance that meets
the product requirements and then restart the application.
written.
Problem: Login screen displays an error similar to the following:
Initialization has failed!
AVUSER permission: ANALYZE ANY missing.
AVSDWUSER permission: CREATE PROCEDURE missing.
AVSDWUSER permission: CREATE SESSION missing.
Reason: The database users where not provided the required database privilege grants.
Solution: Provide the required privilege grants to the database users. See the Database Setup and Management
Guide for more information.
Problem: You see the following ClassCastException error when starting the RSA Identity Governance and
Lifecycle application:

Unable to register service AuthenticationService.

java.lang.RuntimeException: java.lang.ClassCastException:
weblogic.jdbc.wrapper.WrapperSQLXML_oracle_xdb_XMLType cannot be cast to
oracle.sql.OPAQUE
at weblogic.jdbc.wrapper.ResultSet_oracle_jdbc_driver_
ForwardOnlyResultSet.getOPAQUE(Unknown Source)
at com.aveksa.server.utils.ApplicationServerUtil.getOPAQUE
(ApplicationServerUtil.java:189)
at com.aveksa.server.db.StringToXMLTypeMapper.getOPAQUE
(StringToXMLTypeMapper.java:197)
at com.aveksa.server.db.StringToXMLTypeMapper.nullSafeGet
(StringToXMLTypeMapper.java:90)
at org.hibernate.type.CustomType.nullSafeGet(CustomType.java:109)
at org.hibernate.type.AbstractType.hydrate(AbstractType.java:104)
at org.hibernate.persister.entity.AbstractEntityPersister.hydrate
(AbstractEntityPersister.java:2283)
at org.hibernate.loader.Loader.loadFromResultSet(Loader.java:1527)
.....
Solution: Please verify that the Wrap Data Types option is deselected under the Connection Pool tab > Advanced
section. If you are required to deselect the option, you must restart WebLogic for the option change to take
effect.
Runtime
Problem: Change request workflow processes do not execute correctly according to the standard output log file,
which contains descriptions of connection timeout errors.
Reason: The connection pool count for the AVDB data source may need a higher value.
Solution: Increase the connection pool count by a system-appropriate value until the errors stop occurring.
Post-Deployment of RSA Identity Governance and Lifecycle

Problem: Cannot log into the RSA Identity Governance and Lifecycle application.
Reason: The database source may have been configured with the wrong user. For example, the "acmdb"
database source is configured with the "avuser" user. This may cause Creation or Migration SQL scripts to be
executed as the wrong user.
For example, if the "acmdb" data source is configured with the "avuser" user and not "acmdb," the end of the
migrate.log file will indicate that the avuser views have been dropped as indicated (v_*).
Solution: Examine the avdb, avdwdb and acmdb data sources configured on the application server. Validate the
correct user credentials are set, and then re-deploy the application.

Troubleshooting AFX
This chapter describes potential problems you may encounter with deploying, starting, and running AFX server.
The installation process using installation script(installAFX.sh) produces log files that can be examined for
problems during the installation process:
The /tmp/afx-install.log file is generated by the AFX server installation.
Note: Always make sure that RSA Identity Governance and Lifecycle is up and running before you start the AFX
server.
Start Up
Problem: AFX Server fails to start with message: WARNING!! Timed out waiting for AFX applications to start
The AFX log files located in $AFX_HOME/esb/logs contain the following errors:
In the mule_ee.log:
Root Exception stack trace:

valid certification path to requested target
at sun.security.provider.certpath.SunCertPathBuilder.engineBuild
(SunCertPathBuilder.java:197)
at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:255)
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:319)
+ 3 more (set debug level logging or '-Dmule.verbose.exceptions=true' for

everything)
In the esb.AFX-MAIN.log:
Invalid bean definition with name 'jmsConnector' defined in null: Could

not resolve placeholder 'afx.server.activemq.password'
In the esb.AFX-INIT.log:
java.lang.Exception: HTTP response error! Response code=401 ; Reason: RSA

Identity Governance and Lifecycle server was unable to authorize
initialization request.
Reason: This usually indicates that the AFX SSL certificate and/or ID currently configured for this installation
do not match with records in the RSA Identity Governance and Lifecycle database. You may encounter this
problem in the following scenarios:

l The AFX SSL certificate was regenerated using the RSA Identity Governance and Lifecycle application but
the AFX installation was not updated with keystore containing the new certificate. In this case, please
update the AFX installation with latest keystore available for download from RSA Identity Governance and
Lifecycle application.
l RSA Identity Governance and Lifecycle certificate store has been changed but neither the RSA Identity
Governance and Lifecycle server nor AFX installations have been updated with respective keystore
containing new certificate and CA entries. In this case, please update both the RSA Identity Governance
and Lifecycle server and AFX installations with latest respective keystore available for download in the
RSA Identity Governance and Lifecycle application.
l RSA Identity Governance and Lifecycle database was refreshed / restored using a backup that was
generated on another environment (e.g., backup of Production system database was restored on the QA
system database). In this case, additional steps are required to get the SSL certificate configuration in
the database in sync with what's deployed on the RSA Identity Governance and Lifecycle & AFX server
machine(s). Please change the RSA Identity Governance and Lifecycle certificate store and then update
both the RSA Identity Governance and Lifecycle server and AFX installations with latest respective
keystore available for download in the RSA Identity Governance and Lifecycle application.
Solution: Update server.keystore and client.keystore for all remote agents and AFX.
1. Log in to RSA Identity Governance and Lifecycle, and go to Admin > System > Security. In a clustered
environment, perform this step on the single system operations node (SON).
2. Click Change Certificate Store, and click OK to change the root certificate and CA.
3. Click Download and save the server.keystore file to a location on your computer.
4. Go to AFX > Servers, click Change Certificate Store, and click OK to change the client certificate.
5. Click Download and save the client.keystore file to a location on your computer.
6. Stop the ACM and AFX servers.
7. Copy the new server.keystore file to the location on the server where your web server reads the
keystore. For example, $AVEKSA_HOME/keystore.
8. Copy the new client.keystore file to the AFX server under <AFX-server-root>/esb/conf.
9. Update the client.keystore files from the remote agents after you download the corresponding
client.keystore from RSA Identity Governance and Lifecycle.
10. Restart the ACM and AFX servers and verify connectivity with the endpoints.
Issue: Unable to start AFX as either the root or oracle user, and one of the following is displayed:
As root:
aveksa-pno:/home/oracle # afx start

Successful connection detected to RSA Identity Governance and
Lifecycle
Starting AFX Server: Setting MULE_HOME to
/home/oracle/AFX/esb...
Permissions error! Current user does not own all AFX directories
and files.
User must be the owner of /home/oracle/AFX and all its contents

in order to administer AFX.

done
As oracle:
l oracle@aveksa-pno:~> afx start

If 'afx' is not a typo you can run the following command to lookup
the package that contains the binary:
command-not-found afx
bash: afx: command not found
l oracle@aveksa-pno:~> /home/oracle/AFX/bin/afx_server start

Password:
Successful connection detected to RSA Identity Governance and
Lifecycle
Starting AFX Server: Password:
Setting MULE_HOME to /home/oracle/AFX/esb...
Permissions error! Current user does not own all AFX directories and
files.
User must be the owner of /home/oracle/AFX and all its contents in
order to administer AFX.
done
Solution: The AFX server should be started using either the oracle user or afxuser only. Do not use root to start
the AFX Server.
To resolve the permission error, run setPerms.sh as ‘afxuser’ or ‘oracle’( under <AFX_HOME>/bin).
Issue: Unable to install AFX server using the script <aveksa-staging-directory>/deploy/AFX-

scripts/installAFX.sh.
The /tmp/afx-install.log file contain the following errors:
*****************************************************
*****************************************************
Installation started on Fri Aug 5 11:17:48 CEST 2016
*****************************************************
QUIET mode specified. User prompts will be disabled.
Install Summary:
----------------
Install Mode: New Install
AFX_STAGING_DIR /tmp/AFX
AFX_HOME /home/oracle/AFX
MULE_HOME /home/oracle/AFX/mule

ACTIVEMQ_HOME /home/oracle/AFX/activemq
MMC_HOME /home/oracle/AFX/mmc-console
JAVA_HOME /etc/alternatives/java_sdk_1.7.0
JAVA_CMD_DIR /etc/alternatives/java_sdk_1.7.0/bin
AFX_OWNER oracle
AFX_GROUP oinstall
----------------
Cleaning up existing AFX staging directory /tmp/AFX...
Expanding AFX server archive to /tmp/AFX...
Configuring AFX environment script...
Configuring SSL Certificates for AFX Server...
FATAL ERROR!! Failed to create SSL certificate for AFX server using Aveksa
CA
FAILURE!! AFX installation FAILED due to FATAL ERRORS on Fri Aug 5

11:18:53 CEST 2016
*****************************************************
Solution: Verify that the database is up and running.

Appendix C: Maintenance
l Maintaining an RSA Appliance or Software Bundle

l Maintaining a WebSphere Installation
l Maintaining a WebLogic Installation
Maintaining an RSA Appliance or Software Bundle
l Back Up the RSA-Supplied Database

l Importing AVUSER Schema/Data for a Database Restoration/Load
l Migrating the Database
l Operating System Installation Overview
l Firewall Configuration for SUSE
l Firewall Configuration for Red Hat
l Mount an External Drive
l Check for Running Tasks on an Appliance or Server
l Determining the Oracle ASM Partition
l Customize RSA Identity Governance and Lifecycle
l Starting and Stopping RSA Identity Governance and Lifecycle Services
l Starting and Stopping the Oracle Database and Oracle Services
l Backing Up and Restoring RSA Identity Governance and Lifecycle Software
l Updating Database Hostname References in the System
l Changing Database User Passwords
l Changing the Statspack User Name
l Creating a Heap Dump File
l Changing Server Hostname and Network Settings
l Uninstalling RSA Identity Governance and Lifecycle
Back Up the RSA-Supplied Database

Note: This task applies only to installations using an RSA-supplied Oracle database. If you use a customer-
supplied database, see "Back Up the Customer-Supplied Database" in the Database Setup and Management
Guide for instructions.
This task creates a dump (.dmp) file of the AVUSER schema. The file contains all of the application data and
some environment data about a particular system environment.
If you intend to import a dump from one machine to another (which must be running the same RSA Identity
Governance and Lifecycle version from which the dump was created), you may be required to perform
additional configuration on the target machine.
Recommendations

l Back up your database regularly or before making major changes to your system. For example, create a
backup of your appliance database before proceeding with re-installing or upgrading RSA Identity
Governance and Lifecycle software.
l Shut down the RSA Identity Governance and Lifecycle server and AFX before you export a database.
While it is possible to run a backup while RSA Identity Governance and Lifecycle is running, you must
ensure that any crucial data intensive processes, including data collections and review generation, are
not running before you begin the back up. Running a backup with active data-processing in process
may leave backed up data in an inconsistent state.
l To ensure that you only back up essential data, you can use the data purging feature to routinely purge
older data that is not needed for your deployment, and you can use the data archiving feature to archive
older data for auditing purposes. For more information on these features, see the Help topics "Managing
Data Archiving" and "Managing Data Purging".
The dumps are upwardly compatible between Oracle versions.
Procedure
1. Log in to the installation machine as the root user.
2. Enter the following command:

3. Log on to the installation machine as the ‘oracle’ user.

(On a software bundle host): /home/oracle/database/DBA/AVDB/scripts/AVDB_

Export_AVUSER.sh -t _Backup_Pre_Upgrade -o /home/oracle/upgradebackup
(On an appliance host): avdbexport -t _Backup_Pre_Upgrade -o

/home/oracle/upgradebackup
The -t option, provides a tag name that is appended to the standard export file name. The script creates
an export file named Export_AVDB_avuser_Backup_Pre_Upgrade.dmp file in the directory specified by
the -o option. If -o option is not specified, the export file is saved to
/home/oracle/AveksaExportImportDir/
Note: If you also want to compress the dump file, use the -g option.
Note: When using the -i option, ensure that the AVUSER and SYS database user passwords are the
same. Both users are involved in executing the command. For more information on changing passwords,
see Changing Database User Passwords on page 180.
5. Copy the .dmp file to an external location (off the appliance).

6. Check the results of the export process in the following log:
/home/oracle/AveksaExportImportDir/Export_AVDB_avuser_Backup_Pre_
Upgrade.log
Starting with the 7.0.1 product release, a new data encryption handling mechanism is in place which
uses on disk data in conjunction with database data to perform data encryption. When exporting the
database and moving it to a new installation, you must also "pack up" the encryption key data stored on
disk (see Step 4) and moved it along with the database.
162 Appendix C: Maintenance

7. Zip up the master key data in the master key storage directory. This directory is identified by the
application server system property: rsavialg.security.keydir. By default, this directory is
/home/oracle/security.
You will unzip the master key data as part of the steps to import the database described in Import the
AVUSER Schema/Data for a Database Restoration/Load on page 163.
Note: In a clustered environment, if separate copies of the key data are stored on each cluster node,
then only one copy of a key data (any node's key data) needs to be backed up as all areas should contain
the same key data. However, when reinstalling the data , if a node has a local directory specified for
storage of keys, then the key data should be reinstalled to each of these local directories (as specified by
the rsavialg.security.keydir environment variable which each node has set).
Import the AVUSER Schema/Data for a Database Restoration/Load

Note: See the Database Setup and Management Guide for information on importing the AVUSER schema to a
customer-supplied database.
You can import an AVUSER schema/data backup to restore a database or load it on a new machine. You perform
the import procedure for the RSA Identity Governance and Lifecycle Oracle database using the
/home/oracle/database/DBA/AVDB/scripts/AVDB_Import_AVUSER.sh script alias, avdbimport, provided with
the installation. The script uses the Oracle impdp utility to import a dump and perform additional processing
steps after the dump is imported. Note that some data or configurations may be specific to the environment
from which the original dump was taken.
For example, server nodes may need to be updated; this is particularly true when moving clustered
environments. Or directory specific locations configured for collectors may need to change. After you have
imported the database, you must validate that the data is compatible with your database. See Validate
Compatibility of the Database Import for instructions.
Note: If you are using the AFX module and loading a database from a different installation, you must update the
certificates. For more information, see "Change an AFX Server SSL Certificate" in the Access Fulfillment Express
Guide.
The script will complete the following actions:
l Drop and recreate the database users.

l Assign the required grants on those users.
l Run the Oracle impdp command to import the dump file.
l Process entitlements.
l Refresh database statistics.
l Update collection control information.
The dumps are upwardly compatible between Oracle versions.
Procedure
1. Log in to the installation machine as the oracle user.
Starting with the 7.0.1 product release, a new data encryption handling mechanism is in place which
uses on disk data in conjunction with database data to perform data encryption. When exporting the
database and moving it to a new installation, you must also "pack up" the encryption key data stored on
disk and move it along with the database (see Step 2).

2. Unzip the master key data in the master key storage directory.
This is the data that was zipped up in Step 4 in the procedure described in Back Up the RSA-Supplied
Database . (The master key storage directory is identified by the rsavialg.security.keydir environment
variable. The default directory is /home/oracle/security.)
Note: In a clustered environment, if separate copies of the key data are stored on each cluster node,
then only one copy of a key data (any node's key data) needs to be backed up as all areas should contain
the same key data. However, when reinstalling the data , if a node has a local directory specified for
storage of keys, then the key data should be reinstalled to each of these local directories (as specified by
the rsavialg.security.keydir environment variable which each node has set).
3. Stop services. Enter
service aveksa_server stop
4. Restart the database. Enter
service aveksa_server stopdb

service aveksa_server startdb
5. As the 'oracle' user, enter
avdbimport <Options> <Dump_File_Name>
Command options:
l The Dump_File_Name should not include the tag name or file extension (.dmp).
l Use the -t option if the exported dump file was saved with a tag name.
l Use the -i option along with the input directory name if the exported dump file was saved to an
output directory other than the default /home/oracle/AveksaExportImportDir/ directory.
Note: When using the -i option, ensure that the AVUSER and SYS database user passwords are
the same. Both users are involved in executing the command. For more information on changing
passwords, see Changing Database User Passwords.
l Use the -g option to uncompress the dump file if the -g option was used to compress the
exported dump file.
6. Start services:
service aveksa_server start
7. Check the results of the import process in the Import_AVDB_avuser-<date_and_time>.log. By default,

the log file is in the following location:
/home/oracle/AveksaExportImportDir/
If you used the -i option to import the dump file, the log file is located in the input directory.
This is the log for the Oracle impdp import utility command. You can check the progress of the import
using the tail -f command on the log file.
/home/oracle/database/DBA/AVDB/logs/
The directory contains the log files for the import script that list all completed tasks. A log file name in

this directory is based on the Oracle Service name and/or Schema Owner if defined, Import_${ORACLE_
SERVICE_NAME}_${SCHEMA_OWNER}_History.log for example:
Import_AVDB_avuser_History.log
8. If the database schema requires migration, RSA Identity Governance and Lifecycle prompts you to
migrate the schema when you log in to the user interface. Under Schema Migration, enter the password
AuthorizeMigration, and click Migrate Schema.
About Potential Error Messages

This section describes error messages you may encounter during the database import. All can be safely
ignored:
l ORA-06564: object AVEKSA_DATA_DIRECTORY does not exist.
This directory is not in product releases greater than 6.5. Data dumps imported from older versions will
invoke this error because the directory is no longer created.
l ORA-39082: Object type TRIGGER:"AVUSER"."TRIG_AV_JOB_STATS_EMAIL_AI"

created with compilation warnings.
You may see this error message from an import of a database from a previous release because the UTL_
MAIL package is no longer installed in this release. This trigger is removed upon database migration.
l ORA-31685: Object type MATERIALIZED_VIEW:"AVUSER"."MV_

SYSTEMAPPSSUMMARY" failed due to insufficient privileges.
You may see this error message following from a database import from a previous release because this
release no longer grants the ability to create materialized views. The view is removed during database
migration.
l ORA-39082: Object type PACKAGE_BODY:"AVUSER"."AV_JOBSTATS_PKG"

created with compilation warnings.
You may see this error message from a database import from a previous release because this release no
longer grants the ability to see the dba_extents table. The stored procedure that references this table is
removed during database migration.
l ORA-39082: Object type PACKAGE_BODY:"AVUSER"."??????_PKG" created

with compilation warnings.
You may see error messages like this from an database import from a previous release because of
changes to the schema or security privileges during the import. All stored procedure packages are
updated during database migration.
l ORA-00942: table or view does not exist created with exception errors
for retrieval of T_AV_AUDIT_LOG_EVENT_SETTINGS table.
This error can occur at initialization because the table did not exist before version 7.0.
Validate Compatibility of the Database Import
After you import the database on your system, determine whether the database dump is compatible for an RSA

Identity Governance and Lifecycle database installation on an appliance. Determine whether these system
settings from the imported dump are set as follows:
l isAppliance = Yes
l isSoftAppliance = No
Procedure
1. Run the following SQL as avuser:
select * from T_SYSTEM_SETTINGS where PARAMETER like 'is%';
2. If the values above are not set to the correct values, run the following SQL to set them to the correct
values:
update T_SYSTEM_SETTINGS set VALUE='yes' where

PARAMETER='isAppliance';
update T_SYSTEM_SETTINGS set VALUE='N' where

PARAMETER='isSoftAppliance';
Note: For information on validating the compatibility of a database import on a customer-supplied

database, see the Database Setup and Management Guide.
Migrating the Database

In the following situations, you must migrate the database:
l When you are upgrading your RSA Identity Governance and Lifecycle software. An RSA software
upgrade automatically migrates the database when you install on an RSA appliance or a compatible
server, which includes the RSA Appliance, Software Bundle, Websphere, and WebLogic installations.
l Whenever the version of the RSA Identity Governance and Lifecycle software is greater than the version
of the data in the database, for example, you created a fresh installation and you want to use the data
from a previous version, you must migrate the database.
l When you are importing a database dump created on an older version of RSA Identity Governance and
Lifecycle.
If RSA Identity Governance and Lifecycle is already installed and a migration is required, the installation script
displays a prompt that asks whether you want to migrate the database. In most cases, the installer selects yes,
and the migration is performed by the installation script. If the migration is not performed during the upgrade
installation, the RSA Identity Governance and Lifecycle Initialization Status window prompts you to perform the
migration when you attempt to access RSA Identity Governance and Lifecycle.
You must export the existing database to a backup file before you attempt to migrate the database (if you did not
previously create a database backup). See Back Up the RSA-Supplied Database for more information.
Note: Before you migrate the database, ensure that the product tables are not compressed. If the tables are
compressed, the migration process may perform operations that generate an Oracle error such as ORA-39726.
Starting with v7.0.1, a new data encryption handling mechanism is in place which uses on disk data in
conjunction with database data to perform data encryption. When exporting database data and moving it to a
new installation, you must also "pack up" the encryption key data stored on disk and move it along with the
database. For more information, see:

l Back Up the RSA-Supplied Database

l Import the AVUSER Schema/Data for a Database Restoration/Load
To perform a migration manually, use one of the following procedures:
Migrate using the migrate script:

2. Stop services as described in Stopping RSA Identity Governance and Lifecycle Services.
3. Run the migration command:
/home/oracle/deploy/migrate.sh
Output similar to the following appears:
...
The logs are available at: /home/oracle/upgrade/log
The DB schema migration logs available at: /home/oracle/database/log
Scanning migration logs..
Potential errors found in these log files:
Migration logs are available at the locations displayed. If there are errors shown under “Potential errors,”
this may indicate a problem with the migration of your database. Contact Technical Support for
assistance as necessary.
4. Restart the appliance or server.
Migrate from within the RSA Identity Governance and Lifecycle application:
1. In the Initialization Status window, enter the migration password (AuthorizeMigration), and then click
Migrate.
2. Restart RSA Identity Governance and Lifecycle as described in Starting and Stopping RSA Identity
Governance and Lifecycle Services.
Operating System Installation and Upgrade

This section provides an overview of the procedures for installing the SUSE Enterprise Linux 64-bit operating
system on an RSA Appliance. The RSA Appliance ships with the operating system installed. This installation
procedure is provided for the reinstallation and configuration of the operating system, or for upgrading an
appliance using SUSE Enterprise Linux 11 to SUSE Enterprise Linux 12.
The RSA appliance operating system installation process overwrites all data on the appliance, including all
network configuration data. There will be a new hostname and IP address as a result of the operating system
installation. RSA recommends that you note the hostname, IP address, gateway, and DNS nameserver. Ensure
that you back up all data before you install the operating system.
Perform the following steps to complete the RSA appliance operating system installation or upgrade:
1. Verify Operating System Installation Requirements on page 168.

2. Ensure that you have completed the Operating System Installation Prerequisites on page 168.

3. If you are upgrading your appliance operating system from SLES 11, Determine and Record SLES 11
System Details on page 169.
4. Get the Operating System Installation Software and Create the Installation DVD on page 169.
5. Install the Operating System from the Installation DVD on page 170
6. Configure a Network Bond on a Hardware Appliance on page 170.
7. Install RSA Identity Governance and Lifecycle7.2.1 using the Software Bundle scenario. For more
information, see Installation Scenarios on page 13.
8. If upgrading from SUSE Enterprise Linux 11, restore your RSA Identity Governance and Lifecycle. For
instructions, see Restore RSA Identity Governance and Lifecycle on page 179.
Operating System Installation Requirements
l Your appliance must be one of the following model types:
Model Recommended Implementation

Dell R720 Production
Dell R620 Production
Dell R320 Development
l Media requirement:
o Single-sided, single-layer, 4.7GB-capacity DVD
l Upgrade requirement — To successfully migrate the RSA Identity Governance and Lifecycle database
during RSA Identity Governance and Lifecycle 7.2.1 software installation after you install the operating
system, the database must be from RSA product version 4.x or greater. The database must be on a
supported version of Oracle.
Operating System Installation Prerequisites
You must do the following before you perform the operating system installation:
1. Make sure tasks (collections, policies, reports, or reviews for example) are not running on the appliance.
See Check for Running Tasks on an Appliance or Server for details.
2. Stop RSA Identity Governance and Lifecycle services after you have confirmed that there are no tasks
running on the appliance. See Stopping Services for details.
3. Restart the database. See Starting and Stopping the Oracle Database and Oracle Services for details.
4. Ensure that the appliance has a a minimum of 1 GB of free available disk space plus the current size of
the AVDB database (for the backup and upgrade process), and then back up the current installation
software and copy the backup archive to an external drive. This ensures that you are capable of
restoring your current installation if required. See Back up RSA Identity Governance and Lifecycle for
details.
Note: If you have custom indexes or views in place in your deployment, they will be lost during upgrade
process unless they have been rolled into the upgrade release. Contact RSA Support for assistance as
required.
5. Export the database for the current installation and copy the backup file to an external drive. See Back
Up the RSA-Supplied Database for details.
6. If you have SSL server or agent certificates that you would like to save and use with the new or updated
installation, save the server.keystore, serverui.keystores and client.keystore files in the following
directory:

Upgrading from 4.x
/home/oracle/jboss/server/default/deploy/aveksa.ear/aveksa.war/WEB-
INF/certificates
Back up the cacert file from the java directory. This file may contains any additional signing certificates
you may have added.
$JAVA_HOME/jre/lib/security/cacerts
These files can be later used to restore certificates.
Determine and Record SLES 11 System Details
Before you upgrade your appliance operating system to SLES12, record the details of your existing SLES 11
system. This procedure describes how to find the information that you need when you configure the SLES 12
network bond.
Procedure
1. Use the ifconfig to determine the following network bond details for your SLES 11 system, and record
each item in the system details worksheet:
a. The bond0 IP Address is preceded by inet addr:.
For example, in inet addr:1.2.3.4, the bond0 IP address is 1.2.3.4.
b. The bond0 Broadcast Address is preceded by Bcast:.
For example, in Bcast: 1.2.3.255, the bond0 broadcast address is 1.2.3.255.
c. The bond0 Netmask Address is preceded by Mask:.
For example, in Mask: 255.255.255.0, the bond0 netmask address is 255.255.255.0.
2. Use the netstat -rn command to determine the Default Gateway, and record its address in the
system details worksheet. The default gateway contains a destination of 0.0.0.0.
3. Use the hostname -f command to determine the Fully Qualified Domain Name (FQDN) of the
appliance, and record it in the system details worksheet.
4. Enter the first part of the FQDN in the Hostname field of the system details worksheet. For example, if
the FQDN is machine.example.com, machine is the hostname.
5. Use the hostname -d command to determine the Domain Name, and record it in the system details
worksheet.
SLES 11 System Details Worksheet
bond0 IP Address:
bond0 Broadcast Address:
bond0 Netmask Address:
Default Gateway:
Fully Qualified Domain Name (FQDN):
Hostname:
Domain Name:
Get the Operating System Installation Software and Create the Installation DVD
You must download operating system installation files to a computer (not the appliance) from RSA Link at
https://community.rsa.com/community/products/governance-and-lifecycle and create the installation DVD

that you will use to install the operating system on the appliance.
Procedure
1. Log in to RSA Link and download the appropriate SLES 12 ISO image for your deployment.
2. Burn the iso file image (do not copy as a data file) to the DVD using any industry-standard DVD burner
product. See the DVD burner documentation for details.
Install the Operating System from the Installation DVD
Use the DVD to install the SUSE Enterprise Linux 64-bit operating system.
Procedure
1. Attach a keyboard, mouse and monitor to the appliance.
2. Insert the DVD in the DVD drive on the appliance, and power up the appliance.
3. Select F11 on the Dell screen for the boot menu, and then select boot from CDROM/DVDROM under Hard
drive. If the F11 boot menu is not available, use F2 to enter BIOS Setup and change the boot order to
boot from the CDROM/DVDROM.
A menu appears with options to "Boot from local disk" and "Install OS" for different appliance models.
4. Use the arrow keys to highlight Install OS for the appliance model in the menu and press Enter.
If you use the BIOS Setup to change the boot order, you may be returned to the boot menu. If this
occurs, press CTRL+ALT+DEL to reboot and then press F2 to enter the BIOS Setup. Then, restore the
original boot order.
The installation program loads and performs a silent SUSE Enterprise Linux operating system
installation. The installation takes 20 to 30 minutes.
Configure a Network Bond on a Hardware Appliance
After you upgrade your hardware appliance to SLES 12, you must add a network bond device. This procedure is
only required for SLES 12 installed on hardware appliances.
Before you begin

Perform the following procedures before configuring the network bond:
1. Determine and Record SLES 11 System Details on page 169

2. Get the Operating System Installation Software and Create the Installation DVD on page 169
3. Install the Operating System from the Installation DVD on page 170
Procedure
1. Log in to the hardware appliance as the root user.
2. To open a terminal session, click Applications > System Tools > Terminal.
3. Enter the following command to invoke the YaST2 administration tool:
yast
4. In the YaST2 window, under System, select Network Settings.

5. In the Network Settings window, under the Overview tab, click Add to add a new network device.
The Hardware Dialog screen appears.

6. From the Device Type menu, select Bond. Leave the default Configuration Name, which is bond0,
and click Next.
The Network Card Setup screen appears.
7. On the Address tab, enter the following values:
l IP Address - the bond0 IP Address value from the SLES 11 System Details Worksheet
l Subnet Mask - the bond0 Netmask Address from the SLES 11 System Details Worksheet
l Hostname - the Hostname from the SLES 11 System Details Worksheet
8. Select the Bond Slaves tab, and select the slave network cards to assign to the network bond.
9. Click Next.
10. Select the Hostname/DNS tab, and enter the following values:
l Hostname - the Hostname from the SLES 11 System Details Worksheet
l Domain Name - the Fully Qualified Domain Name from the SLES 11 System Details
Worksheet
l Name Server - The IP address of your domain name server (DNS)
l Domain Search - The domain name used to resolve hostnames without a specified domain.
11. Select the Routing tab, and in the Default IPv4 Gateway field, enter the Default Gateway from the
SLES 11 System Details Worksheet. Leave the Device menu at its default value.
12. Click OK, and exit YaST2.
13. In the terminal window, enter the following command to view the network configuration:
ifconfig -a | less
14. Verify the following details in the output:

l The inet addr matches the bond0 IP Address from the SLES11 SP3 System Details Worksheet
l The Mask address matches the bond0 Netmask Address from the SLES11 SP3 System Details
Worksheet
l The status is described as UP.
15. Enter the following command to verify that the Default Gateway matches the value specified in the
SLES 11 System Details Worksheet. The default gateway has a corresponding destination of 0.0.0.0.
netstat -rn
16. Reboot the system, and perform the following steps to confirm that the appliance network has been
successfully configured:
a. Repeat steps 14-16.
b. Connect to this appliance from a remote client using SSH.
After you finish

1. Install RSA Identity Governance and Lifecycle as described in Software Bundle Installation on page 37.
2. If upgrading from SLES 11, restore your RSA Identity Governance and Lifecycle. For instructions, see
Restore RSA Identity Governance and Lifecycle on page 179.
Firewall Configuration for SUSE

A Software Bundle installation does not open and redirect required TCP ports in the firewall on SUSE. Follow the
procedure in this section to open and redirect the ports. See Port Prerequisites for information about ports.

Procedure
1. Open the following file with a text editor:
/etc/sysconfig/SuSEfirewall2
2. Append the following port number string "21 22 1158 1555 8443 8444" to the FW_SERVICES_EXT_TCP
options line (space separated).
For example:
FW_SERVICES_EXT_TCP="21 22 1158 1555 8443 8444"
Note: Your internal IT staff might mandate additional ports to be added for infrastructure tools such as
monitoring programs.
3. Append the following port number string "0/0,0/0,tcp,443,8443 0/0,0/0,tcp,444,8444" to the FW_
REDIRECT options line (observing the comma and spacing syntax in the example).
For example:
FW_REDIRECT="0/0,0/0,tcp,443,8443 0/0,0/0,tcp,444,8444"
4. Run the following command(s) to apply these changes:
For SuSE 11 SP3:
/etc/init.d/SuSEfirewall2_init restart
/etc/init.d/SuSEfirewall2_setup restart
For SuSE 12 SP2:
systemctl restart SuSEfirewall2 SuSEfirewall2_init
Firewall Configuration for Red Hat

A Software Bundle installation does not open and redirect required TCP ports in the firewall on Red Hat. Follow
the procedure in this section to open and redirect the ports. See Port Prerequisites for information about ports.
Procedure
1. Open the following file with a text editor:
/etc/sysconfig/iptables
2. Add lines like the following, for example, to your firewall section in iptables to open the ports:
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 21

-j ACCEPT

-j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport

8443 -j ACCEPT


8444 -j ACCEPT

1555 -j ACCEPT

1158 -j ACCEPT
See the example in Step 4.
3. Add a network address translation section if you don’t have one to perform port redirection from the
standard https port. This section typically appears before the “*filter” section. If you already have a *nat
section, add the two REDIRECT lines. Replace bond0 with the name of your primary network interface.
*nat
:PREROUTING ACCEPT
:POSTROUTING ACCEPT
:OUTPUT ACCEPT
-A PREROUTING -i bond0 -p tcp -m tcp --dport 443 -j REDIRECT --to-

ports 8443

ports 8444
COMMIT
4. Verify that your /etc/sysconfig/iptables file should look similar to the following:
##################### Start of insertion from Step 3 #####################
*nat
:PREROUTING ACCEPT
:POSTROUTING ACCEPT
:OUTPUT ACCEPT

ports 8443

ports 8444
COMMIT
##################### End of insertion from Step 3 #####################
*filter
:INPUT ACCEPT

:FORWARD ACCEPT
:OUTPUT ACCEPT
:RH-Firewall-1-INPUT -
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp -m icmp --icmp-type any -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
##################### Start of insertion of from Step 2 #####################

-j ACCEPT

-j ACCEPT

8443 –j ACCEPT

8444 –j ACCEPT

1555 –j ACCEPT

1158 –j ACCEPT
##################### End of insertion of of from Step 2

#####################
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT
5. Restart the iptables for the changes to take effect. Enter the following command:
"service iptables restart"
Mount an External Drive

Perform this procedure as root if you do not have an off-appliance location to store RSA Identity Governance and
Lifecycle installation software and the database and you are required to mount an external drive.
Procedure:
1. Connect the drive to the appliance.
2. Run the following command to find the attached drive:

fdisk -l | less
3. Run the following command to partition the drive if necessary:
fdisk /dev/sdc
From the fdisk command prompt:

a. Enter "p" to display the partitioning of the disk.
b. Enter “n” to create a new partition and accept all defaults.
c. Enter “p” to confirm that the partition was successfully created. You should see output similar to
the following:
Disk /dev/sdc: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdc1 1 60801 488384001 83 Linux
d. Enter “w” to write all of your changes to the superblock.
4. Create an ext3 file system on the newly created partition. For example:
mke2fs -j /dev/sdc1 /misc
Once the formatting has completed, mount the drive as follows:
mount /dev/sdc1 /misc
where:
/dev/sdc is the device for the drive that you just added, and the “1” is for the first partition of that drive.
Check for Running Tasks on an Appliance or Server

Procedure
2. Access the Monitoring feature under the Admin tab to determine whether tasks are running.
Wait until all tasks have completed before proceeding with the upgrade.
Determining the Oracle ASM Partition

Note: This procedure pertains to a RSA-provided database scenario. In a customer-supplied database
scenario, consult the DBA as required.
If you are doing an appliance re-installation after an uninstall, you will be prompted for the ASM partition during
installation. You can check the previous setting with the following command:


grep ASM_PARTITION /tmp/Aveksa_System.cfg
If /tmp/Aveksa_System.cfg is not present, or this has no setting, you must determine the ASM partition.
l For Dell R720 and Dell 2900 appliances, the ASM partition is sdb1.
l For all other appliances, the ASM partition is sda3.
You can confirm the ASM partition with the following command. You must precede the partition name with /dev/.
For example:
service oracleasm querydisk /dev/sdb1
Example output:
Disk "/dev/sdb1" is marked an ASM disk with the label "VOL1"
Customize RSA Identity Governance and Lifecycle

You can customize RSA Identity Governance and Lifecycle by modifying an aveksa.ear file. RSA provides a utility
(customizeACM.sh in <aveksa_staging_directory>/deploy/ACM-scripts/) that allows you to conveniently
extract an aveksa.ear file and use the utility to rebuild a customized version. This utility uses the ORACLE_
HOME/archive directory to store archived aveksa.ear files that have been deployed and to maintain information
about the currently deployed aveksa.ear.
Procedure
1. Log on to the appliance as the admin user.
2. Verify that RSA Identity Governance and Lifecycle is running. Enter
sudo service aveksa_server status
If RSA Identity Governance and Lifecycle is running, the following message displays:
Aveksa Compliance Manager Server is running
If the message indicates that the server is not running, enter
3. Change to the oracle user.

4. Go to <aveksa_staging_directory>/deploy/ACM-scripts/.
5. Run the customizeACM.sh script to extract the .ear file:
customizeACM.sh -c <path to the ear file>
The contents of the .ear are extracted to a directory in the following location: /tmp/customizeACM/.
Note: If you do not specify the path to the .ear file, the script prompts you to use the currently deployed
.ear file. If you want to use the currently deployed .ear, enter yes. If you do not want to use the currently
deployed .ear, enter no.
6. Go to /tmp/customizeACM/ and modify the extracted files.

7. When you finish modifying the files, run the customizeACM.sh script again to rebuild the .ear file. From
<aveksa_staging_directory>/deploy/ACM-scripts/, enter

customizeACM.sh -d
The script performs the following tasks:
l Archives the new .ear file to the following location, appending a time and date stamp to the
name: /archive.
l Deploys the new customized .ear file.
Starting and Stopping RSA Identity Governance and Lifecycle Services

Follow the procedures in this section any time you are required to start or stop RSA services.
Starting RSA Identity Governance and Lifecycle Services
This procedure starts the RSA Identity Governance and Lifecycle server and all services.
Procedure
1. Log in to the installation machine as the ‘admin’ user.
Stopping RSA Identity Governance and Lifecycle Services
You are required to stop the RSA Identity Governance and Lifecycle server and all services prior to upgrading
RSA software.
Procedure
Starting and Stopping the Oracle Database and Oracle Services

Restarting the database ensures that it is brought back to a clean state (no pending tasks are running). The
Oracle Enterprise Manager (OEM) should be running whenever the database is running. The port 1158 should
always be open in the firewall to allow access.
Note: This procedure pertains to an RSA appliance database scenario. In a customer-supplied database
scenario, consult the DBA for the database.
To restart the database:

2. Shutdown the database:
sudo service aveksa_server stopdb
3. Start the database:
sudo service aveksa_server startdb

4. You can check the status of the operations using the following command:
sudo service aveksa_server statusdb
To restart all Oracle services:

2. Shutdown the all Oracle services, including OEM:
sudo service aveksa_server stoporacle
3. Start all Oracle services, including OEM:
sudo service aveksa_server startoracle
You can check the status of database operations, including OEM operations, using the following
command:
sudo service aveksa_server statusoracle
To start, stop, and check the status of OEM:

l Start OEM: sudo service aveksa_server startoem
l Stop OEM: sudo service aveksa_server stopoem
l Check status: sudo service aveksa_server statusoem
Note: ACMWatchdog.sh will automatically start OEM if AVDB is running on the machine if OEM was not
explicitly stopped through "service aveska_server stopoem" or "service aveksa_server stoporacle."
Backing Up and Restoring RSA Identity Governance and Lifecycle Software

You can back up your RSA Identity Governance and Lifecycle software and restore the backup on a different
machine as required (system failure for example) or if you want to revert back to a previous version of a patch. A
restore lets you rollback/restore the production environment to a previous state. The back up process creates a
backup file of the application server and the associated directories configured for that running version of the
application, including any patches. The process does not back up your database or the installed Oracle
software. Always back up a corresponding version of your database when you back up your RSA Identity
Governance and Lifecycle installation. See Back Up the RSA-Supplied Database for more information.
RSA recommends that you copy the backup file to an external drive. Restoration of a backup must be on a
machine that has the same version of the backup installed. If, for example, you were restoring a backup of
v6.0.2, you would be required to install v6.0.2 on the restoration target machine. You would also restore the
database schema from the saved database dump. Depending on the version you plan to restore, you may be
required to install a new operating system, which overwrites all data on the appliance. Consult the installation
guide for your restoration version to ensure you meet all system requirements for that version.
Back up the RSA Identity Governance and Lifecycle Application
The following procedure applies only to appliance, software bundle, and virtual application deployments.
This section outlines the steps to backup the RSA Identity Governance and Lifecycle configuration settings so
they can be restored if necessary. See Restore RSA Identity Governance and Lifecycle for information on
restoring a software backup.
RSA recommends that you store backups off of the system.

Procedure
1. Log in as the root user.
2. Stop AFX if it is installed:
<path-to-AFX>/afx stop
3. Change to the following directory path:
cd <aveksa_staging_directory>/deploy/ACM-scripts/
./acm_backup.sh
5. Enter ‘yes’ to perform the backup operation.
The command creates a file named Backup<product version>.tar in the following directory:
ORACLE_HOME/AveksaExportImportDir
Keep the Backup<product-version>.tar file in a safe place where it can be accessed in case you need to restore.
Restore RSA Identity Governance and Lifecycle
This procedure describes how to restore the software installation from a backup file. The restore script
performs its operations by overlaying changes onto an existing environment installed to the same version from
which the backup was taken.
Note: You can restore a product version only on a machine that has the same version installed. You must also
use a database dump from the same version to restore the database data and associated KEK and keystore files.
Procedure
2. Copy the Backup<version>.tar file from the off-appliance drive where you copied the backup to the
following directory:
/home/oracle/AveksaExportImportDir
3. Change to the following directory:
/home/oracle/deploy
4. Enter the following command to restore the RSA Identity Governance and Lifecycle deployment:
./acm_restore.sh
Output indicates the progress of the restoration.
5. Import a database dump corresponding to the version of the RSA Identity Governance and Lifecycle
software dump you just restored. See Importing AVUSER Schema/Data for a Database Restoration/Load
for more information.
6. Migrate the database as describe in Migrating the Database.

7. Restart the database as described in Starting and Stopping the Oracle Database and Oracle Services.
8. Start services as described in Starting RSA Identity Governance and Lifecycle Services.
Updating Database Hostname References

Update all references to the database hostname in the system when the database hostname has been changed.
Procedure
1. Shut down all application servers that use the database instance.
2. Shut down the database.
3. Move the database to the new host or change the host's name and/or IP address.
4. Start the database instance.
5. On the application server host:
a. In /home/oracle/Aveksa_System.cfg, update the following variables:
Setting Variable
Oracle IP REMOTE_ORACLE_IP=
Port REMOTE_ORACLE_PORT=
SID ORACLE_SID=
b. In /home/oracle/wildfly/standalone/configuration/aveksa-standalone-full.xml, update the four

instances of <connection-url>, for AVDB, ACMDB, AVDWDB, and AVPERF, using the appropriate
values for the Oracle IP, port, and SID for your environment.
<connection-url>jdbc:oracle:thin:@//HOST:PORT/SID
For example
<connection-url>jdbc:oracle:thin:@//myOracleBox:1521/avdb60
c. In the /home/oracle/instaclient_*/tnsnames.ora Oracle listener configuration file, update the

following data:
( (ADDRESS = (PROTOCOL = TCP)(HOST = )
d. System scripts may reference the Oracle SID. Update the setDeployEnv.sh script in the
/home/oracle and /root directories with the applicable SID for your environment to ensure that
the scripts to execute properly.
export ORACLE_SID=AVDB
6. Start the application server.
Changing Database User Passwords

This section describes how to change the following RSA Identity Governance and Lifecycle database user
passwords:
l AVUSER
l AVDWUSER
l ACMDB

l PERFSTAT (or otherwise defined user name)

l SYS
With the exception of SYS, which is a default Oracle database user, an appliance installation creates these users
with default passwords after the Oracle database is installed. In a customer-supplied database installation
scenario, the passwords are defined for the database users by the DBA.
RSA Identity Governance and Lifecycle stores database user passwords encrypted. Database user information is
stored in the following locations:
l /home/oracle/wildfly/standalone/configuration/aveksa-standalone-full.xml — Stores the database

information needed to connect to the AVDB database.
l Aveksa_System.cfg — Stores high-level information about the RSA Identity Governance and Lifecycle
environment and the users used to access and work with RSA Identity Governance and Lifecycle.
Note: The SYS user password is stored only in Aveksa_System.cfg.
If you are required to change the password for a database user, it must first be changed within the database
before you change it in RSA Identity Governance and Lifecycle files. Repeat the following procedure for each
database user whose password you want to change. The AVUSER database user is used as an example in the
following procedure.
Procedure:
1. As the oracle user, change the database user password in the database using the following
SQL command syntax:
alter user AVUSER identified by <a_cleartext_password>;
2. As the oracle user, update the password property with the cleartext password you want to change for
the database user in /home/oracle/Aveksa_System.cfg. Remove the braces ( { } )when you set the
cleartext password unless they are actually part of the password.
Note: The cleartext password in Aveksa_System.cfg is encrypted in the next step.
Database Username Password Property

AVUSER AVEKSA_PASS
AVDWUSER AVEKSA_REPORTS_PASS
ACMDB AVEKSA_PUBLIC_DB_PASS
PERFSTAT AVEKSA_AVPERF_PASS
SYS SYS_PASS
3. As the root user, encrypt the password by running the following command for the database user from
the /home/oracle/deploy directory:
./generateLoginKey.sh <avuser|avdwuser|acmdb|perfstat|sys>
The command returns the encrypted password.
4. As the oracle user, update the security domain name under security subsystem with the encrypted
password you want to change in $AVEKSA_WILDFLY_HOME/standalone/configuration/aveksa-

standalone-full.xml:
Security Domain
Database Username
Name
EncryptedPassword-
AVUSER
AVDB
EncryptedPassword-
AVDWUSER
AVDWDB
EncryptedPassword-
ACMDB
Note: There are two

places where the file
has
ACMDB "EncryptedPassword-
ACMDB". It is the
second one that must
be modified. (Where
<module-option
name="password"
value= >.)
EncryptedPassword-
PERFSTAT
AVPERF
5. As the oracle user, restart RSA Identity Governance and Lifecycle to apply your changes:
acm restart
Changing the Statspack User Name

The perfstat user is the user created when the Oracle statspack was installed. If this schema was created with a
different user (default is “perfstat”) follow the instructions in this section to configure RSA Identity Governance
and Lifecycle with the correct username.
Procedure
Update the occurrences of perfstat username with the new username value in the following file:
/home/oracle/wildfly/standalone/configuration/aveksa-standalone-full.xml
Search for instances of the EncryptAVPERFPassword in the file. Change the username field with the configured
user for statspack. For example:
<application-policy name="EncryptAVPERFPassword">
<authentication>
<login-module
code="org.wildfly.resource.security.SecureIdentityLoginModule"
flag="required">

<module-option name="username">MyStatsUserName</module-
option>
<module-option name="password">-91f121c430503dd</module-
option>
<module-option
name="managedConnectionFactoryName">wildfly.jca:service=Loc
alTxCM,name=avdb</module-option>
</login-module>
</authentication>
</application-policy>
Creating a Heap Dump File

RSA Identity Governance and Lifecycle automatically creates a heap dump file in the /home/oracle directory
when it detects an “OutOfMemoryError” Java heap space error, which can be used to troubleshoot heap errors.
The file format:
acm-heap-dump-date.hprof
You can also create a heap dump file at any time using the following commands:
service aveksa_server heap-dump — Creates a heap dump in /home/oracle directory.
service aveksa_server heap-dump-force — Forces the creation of a heap dump file in an unresponsive process.
Pruning the Job Statistics Table

The job statistics table, T_AV_JOB_STATS, is used by jobs running in RSA Identity Governance and Lifecycle to
log the activities that they are performing. The biggest contributors to the size of this table are collection runs
and review generation. That activity data is used for diagnosing functional or performance problems; therefore,
the records in this table are not required to be maintained indefinitely.
If unnecessary records are not pruned (or deleted) from this table it can become extremely large. This is
detrimental in the following ways:
l Larger total database size

l Larger/longer database backups and restores
l Longer database statistics runs (as this table will be eligible for periodic statistics compilations)
l Larger/longer database backup uploads to RSA support when requested.
You can use the following method to prune the table:
Admin > Monitoring > Action button — Provides multiple data run deletion options. For more information, see
Prune the Statistics Table from the Monitoring Page.
Prune the Statistics Table from the Monitoring Page
Note: For more information on managing data runs, see the Help topic, "Managing Data Runs."
Procedure:

1. Go to Admin > Monitoring.

2. From the Action button, select the run deletion option you want to use to prune the statistics table.
Changing Server Hostname and Network Settings

If the appliance requires a new hostname or network settings, because it is being moved to another network for
example, you can use the scripts, located in the /usr/bin/ directory, to update system files:
l modifyhostname.sh
l modifynetworksettings.sh
You must run these commands as the root user. For either or both modifications, you must reboot the system
for the changes to take effect.
Note: Do not use this procedure for virtual application deployments. To change the hostname or network
settings on a virtual application, use the RSA Identity Governance and Lifecycle virtual application setup
interface. For more information, see Set Up the RSA Identity Governance and Lifecycle Virtual Application on
page 54.
To change the hostname:

Run the modify hostname script to change the hostname:
modifyhostname.sh requires the server to be stopped (service aveksa_server stop), but Oracle must be
running (service aveksa_server startoracle) if it is installed..
modifyhostname.sh <hostname.domain name>
To change the network settings:

Run the modify network settings script to change the network settings for the system:
modifynetworksettings.sh requires the server and oracle to be stopped (service aveksa_server stop and service
aveksa_server stoporacle).
modifynetworksettings.sh <newIP> <newNetmask> <newGateway>
For example, <newIP>=192.168.20.229, <newNetmask>=255.255.254.0, and <newGateway>=

192.168.20.1
Where:
newIP — IP address of the appliance
newNetmask — Subnet mask
newGateway — Network gateway
After you finish
After you modify the hostname, you must perform the following steps to update the server.keystore and
client.keystore.
1. Log in to RSA Identity Governance and Lifecycle, and go to Admin > System > Security. In a clustered
environment, perform this step on the single system operations node (SON).
2. Click Change Certificate Store, and click OK to change the root certificate and CA.
3. Click Download and save the server.keystore file to a location on your computer.

4. Go to AFX > Servers, click Change Certificate Store, and click OK to change the client certificate.
5. Click Download and save the client.keystore file to a location on your computer.
6. Stop the ACM and AFX servers.
7. Copy the new server.keystore file to the location on the server where your web server reads the
keystore. For example, $AVEKSA_HOME/keystore.
8. Copy the new client.keystore file to the AFX server under <AFX-server-root>/esb/conf.
9. Update the client.keystore files from the remote agents after you download the corresponding
client.keystore from RSA Identity Governance and Lifecycle.
10. Restart the ACM and AFX servers and verify connectivity with the endpoints.
Uninstalling RSA Identity Governance and Lifecycle

Use the following to procedure to uninstall RSA Identity Governance and Lifecycle in the event that the
installation process fails.
Note: RSA recommends that you back up your database and any other data that may be lost during the
uninstallation process. This may include any localized files you have changed, keystores with installed
certificates, or configuration files that were modified.
Procedure
1. Log in to the installation machine as the ‘root’ user.
2. Stop all RSA Identity Governance and Lifecycle and Oracle services. See Stopping RSA Identity
Governance and Lifecycle Services and Starting and Stopping the Oracle Database and Oracle Services
for more information.
3. Navigate to the following directory:
cd /tmp/aveksa/staging/deploy
./uninstall.sh
You can check results of the uninstall process in the uninstall log file in the /tmp directory. For example:
/tmp/aveksa-uninstall.log.Dec-21-2011.07.42.26
Configuring the Test Authentication Module

This should only be used on a system for testing purposes and never used in a production environment. Delete
the test authentication module before you migrate a test installation to a production environment. See the
Administrators Guide for information on how to delete an authentication source.
RSA provides a sample authentication source that can be used for a demonstration or testing installation that
takes any known user name in the system with any password provided. The test authentication module is often
used to simplify the process of testing with large numbers of users. The test module is associated with an
identity collector that collects the identities into the system.
To set up the authentication module, you must create an authentication source. The JAAS module required for
the authentication source is pre-configured in the application server. This section demonstrates how to create

the authentication source named “TestAuthProvider.” You can use any name, and you can create multiple test
authentication modules for different Identity collectors.
You must restart RSA Identity Governance and Lifecycle after you configure the test authentication module.
Procedure
Use the following SQL commands to insert the test authentication source, TestAuthProvider, into database (the
commands should be issued from the user: avuser):
INSERT INTO T_AUTH_CONFIGURATIONS
(ID, IDC_ID, AUTH_PROVIDER_NAME, AUTH_CONFIGURED_PROPERTIES,AUTH_PROVIDER_

TYPE,AUTH_PROVIDER_CLASS)
VALUES(AUTH_CONFIGURATION_SEQUENCE.nextval, 1, 'TestAuthenticator',
'<?xml version="1.0" encoding="UTF-8"?><properties></properties>',
'TestAuthProviderType',
'com.aveksa.server.authentication.TestLoginModule');
The example SQL configures the authentication source associated with the Identity collector with IDC_ID = 1.
This assumes the identity collector identified by IDC = 1, which is typically the first identity collector configured
in your environment. It may not be the correct ID for the collector you want to associate with the test
authentication module in your environment. Therefore, you should run the SQL above with the IDC_ID of the
collector you choose to associate with the authentication module.
To get a list of the identity collectors and their IDs, run the following SQL:
select ID, Name from T_DATA_Collectors where collector_

type='DBIdentityCollector';
This displays a list of IDC_ID's associated with users. For example:
IDC_ID
----------
Next, check the name, status, and type of those IDC_IDs to provide more information when determining the
appropriate IDC to configure using the list of IDC_ID's from the previous step. For example:
select name, id, collector_type, status from t_data_collectors where id in

(3, 7);
NAME ID COLLECTOR_TYPE STATUS
----------------------- ---- ------------------------- ---------
Corp Ent User Collector 3 DBIdentityCollector Active
External Services Coltr 7 LdapIdentityCollector Active
So if you decide to configure the test authentication module against the corporate users from Collector ID 3,
specify that value for the IDC_ID in the SQL as shown below:

(ID, IDC_ID, AUTH_PROVIDER_NAME,
AUTH_CONFIGURED_PROPERTIES,AUTH_PROVIDER_TYPE,AUTH_PROVIDER_CLASS)
Note: You must restart RSA Identity Governance and Lifecycle after you configure the test authentication
module

Maintaining a WebSphere Installation
l Accessing RSA Identity Governance and Lifecycle

l Modifying the Enterprise Archive
l Check for Running Tasks in RSA Identity Governance and Lifecycle
l Localization Configuration
l Changing Database User Names in RSA Identity Governance and Lifecycle
l Changing Database Tablespace Names in RSA Identity Governance and Lifecycle
l Changing Database User Passwords in RSA Identity Governance and Lifecycle
l Updating RSA Identity Governance and Lifecycle on WebSphere with a Patch
l Uninstalling RSA Identity Governance and Lifecycle from WebSphere
Accessing RSA Identity Governance and Lifecycle

The virtual host where RSA Identity Governance and Lifecycle was installed (default_host in this example) lists
the ports available for HTTP (9080) versus HTTPS (9443) access. Unless there is a web proxy fronting the
application server, you can access RSA Identity Governance and Lifecycle using one of the following URLs:
l http://<machine>:9080/aveksa/main
l https://<machine>:9443/aveksa/main
The ports referenced are typical default ports for WebSphere. These may vary. In that case, consult the
WebSphere administrator who installed the RSA Identity Governance and Lifecycle software for the correct
ports.
Modifying the RSA Identity Governance and Lifecycle Enterprise Archive

To modify RSA Identity Governance and Lifecycle, you must unzip the aveksa.ear and aveksa.war files, make
changes required for customization, and then re-zip the files before deploying or re-deploying them on
WebSphere.
Procedure
1. Set up a working directory, “new_ear” for example.
2. Copy the aveksa.ear file to the working directory.
3. Create a temporary ear directory, “ear_dir” for example, in the working directory.
4. Create a temporary war directory, “war_dir” for example, in the working directory.
5. Unzip aveksa.ear in the temporary ear directory (ear_dir):
cd ear_dir
jar -xvf ../aveksa.ear
6. Unzip aveksa.war in the temporary war directory (war_dir):
cd ../war_dir
jar -xvf ../ear_dir/aveksa.war
188
7. Complete any modification/changes to the files within the ear_dir or war_dir directories.
For example, if you created your database instance with non-default names (for AVUSER, AVDWUSER,
etc) or non-default database tablespace names, then you need to edit Aveksa_System.cfg file to add the
appropriate values to the aveksa.ear.
8. Rebuild the modified aveksa.war:
cd war_dir
jar uvfm ../ear_dir/aveksa.war META-INF/MANIFEST.MF *
9. Rebuild the modified aveksa.ear:
cd ../ear_dir
jar uvfm ../aveksa.ear META-INF/MANIFEST.MF *
The aveksa.ear in the working directory now has been updated with the changes. You can now specify
the path for your modified ear for deployment updates. For example:
new_ear/aveksa.ear
10. Make sure the .ear file has read permissions for the account ID (for example, wasadmin) that will need to
open it.
Check for Running Tasks in RSA Identity Governance and Lifecycle

Procedure
2. Click the Admin menu and select Monitoring to determine whether tasks are running.
Configure Non-SSL Port for WebSphere

Configure port 8080 if a non-SSL agent is installed on the same machine as the RSA Identity Governance and
Lifecycle application server. For example, port 8080 is used when an ITIM agent is installed on the RSA Identity
Governance and Lifecycle machine.
You do not need to open the port on any firewalls, but you must configure the port as described in this task.
In a cluster, perform this task for each server.
Procedure
1. In the WebSphere console, click Servers > Server types > WebSphere application servers > Select
server.
2. Create a new Web container. Click Container Settings > Web Container Settings > Web container
transport chains > New.
3. Configure the following settings:
l Transport Name: WCAveksa8080
l Transport chain Template: default chain template Chain_1
189
4. Click Next, and configure the following settings:

l Port Name: ACMPort8080
l Host *
l Port: 8080

6. From the Environment menu, click Virtual Hosts > Default_host > Host Aliases > New.
l Host *
l Port: 8080

9. Restart the application server for the port changes to take effect.
Localization Configuration
RSA Identity Governance and Lifecycle can be localized to English, French, and German. By default, the RSA
Identity Governance and Lifecycle user interface is set to the language to which your internet browser is set.
This section describes how to create your own custom localization files for additional languages.
Procedure
1. Translate the contents of the following file to the language you want to provide as a localization option:
aveksa.ear/aveksa.war/WEB-INF/classes/com/aveksa/gui
/strings.properties
2. Save the file in the following format:
/strings_XX.properties
where
XX is the ISO-639 two-letter code of the language you want to use. The following table contains
examples of the codes:
Language Code Language
de German
fr French
ja Japanese
ko Korean
zh Chinese
3. Modify the Aveksa ear file with the additional localization file and then redeploy the file into the
application server and restart the server. For more information, see Modifying the Enterprise Archive.
Note: Custom localization files are deleted when you upgrade system software. Therefore, before you upgrade
you must save any custom files to a location that is not on the system. Also, you must update the translation as
190
new strings are introduced to the product between releases. Localization of online help is not currently
supported.
Changing Database User Names in RSA Identity Governance and Lifecycle

This section describes how to change the RSA Identity Governance and Lifecycle database user schema names
for the following authentication users if the names in the database have changed:
Procedure
1. Open the aveksa.ear/aveksa.war/WEB-INF/Aveksa_System.cfg file for editing.
2. Replace the default (or previously specified non-default) name value with the names configured for the
database:
AVEKSA_USER=AVUSER
AVEKSA_REPORTS_USER=AVDWUSER
AVEKSA_PUBLIC_DB_USER=ACMDB
3. Modify and redeploy the Aveksa ear file with the changes you made to the Aveksa_System.cfg file. See
Modifying the Enterprise Archive for more information.
Changing Database Tablespace Names in RSA Identity Governance and Life-

cycle
This section describes how to change the database tablespace names used by RSA Identity Governance and
Lifecycle when non-default tablespace names are configured in the database used by RSA Identity Governance
and Lifecycle.
The well known default tablespace names are:
l DATA_256K
l DATA_1M
l DATA_25M
l DATA_50M
l INDX_256K
l INDX_1M
l INDX_25M
l INDX_50M
l DEFAULT_TABLESPACE
l TEMP_TABLESPACE
If non-default names are configured in the database, you must update the Aveksa_System.cfg file and modify
and redeploy the aveksa ear file.
Procedure
191
1. Open the aveksa.ear/aveksa.war/WEB-INF/Aveksa_System.cfg file.

2. Replace the default name with a non-default name as follows:
l DATA1_TABLESPACE=DATA_256K
l DATA2_TABLESPACE=DATA_1M
l INDX1_TABLESPACE=INDX_256K
l INDX2_TABLESPACE=INDX_1M
3. Designate a tablespace for the DEFAULT_TABLESPACE variable and, optionally, one for the TEMP_
TABLESPACE variable:
1. DEFAULT_TABLESPACE= DATA_1M
2. TEMP_TABLESPACE=TEMP
If, for example, you created 2 tablespaces for indexes (small, large) and 2 Tablespaces for data (small,
large) you might have an Aveksa_System.cfg that looks like this:
l DATA1_TABLESPACE=ACM_DATA_SMALL
l DATA3_TABLESPACE=ACM_DATA_LARGE
l INDX1_TABLESPACE=ACM_INDEX_SMALL
l INDX3_TABLESPACE=ACM_INDEX_LARGE
l DEFAULT_TABLESPACE=ACM_DATA_LARGE
4. Save and close the aveksa.ear/aveksa.war/WEB-INF/Aveksa_System.cfg file.
Modify and deploy the aveksa.ear file application server. See Modifying the Enterprise Archive for more
information.
Changing Database User Passwords in RSA Identity Governance and Life-

cycle
This section describes how to change the RSA Identity Governance and Lifecycle database user passwords for
the following authentication users if the passwords for the users are changed in the database:
l AVUSER
l AVDWUSER
l ACMDB
Procedure
1. From the Security menu, select, Global Security
2. Under Authentication, expand Java Authentication and Authorization Service and select J2C
authentication data.
192
3. Click the name of the user you want to edit.

4. Change the password field with the new password
Password: <enter password>
RSA recommends that you then test the connections for the ACM JDBC data sources.
Updating RSA Identity Governance and Lifecycle on WebSphere with a

Patch
A patch is an interim release of an RSA Identity Governance and Lifecycle version that addresses a specific
customer requirement. Patches undergo limited testing and should only be applied to address specific
requirements. RSA recommends that you back up the database before installing a patch. Consult
support@aveksa.com for questions about patches. Patches are available from RSA SecurCare Online at
https://knowledge.rsasecurity.com.
A patch is version specific, that is, it can only be installed on the base version for which it was developed. For
example, you cannot update product version X with a version Y patch without first installing version Y. Also,
patches are cumulative, that is, they include all fixes included in previous patches. For example, if P02 (patch
version 02) was previously installed you can install P05 without having to first install P03 and P04. RSA
recommends that you do not attempt to install a previous version of a patch over a later version of a patch.
Procedure
1. Download the following files from RSA SecureCare Online:
l PatchInfo.txt: Contains information on the fixes provided by the patch and any prerequisites that
must be met before you install it.
l Patch_<version>_Release_Notes.pdf
l ACM-WebSphere-<product version>_P0<version number>.tar.gz
2. Uncompress and untar the ACM-WebSphere-<product version>_P0<version number>.tar.gz file. This

extracts the ear file to be deployed: aveksa.ear
Follow the instructions in the Upgrade and Migration Guide to deploy the ear file. This involves a full
install of the ear. Any modifications made in your installation will also need to be made to the hotfix ear
before deployment. See Modifying the Enterprise Archive for more information.
Uninstalling RSA Identity Governance and Lifecycle from WebSphere

Procedure
1. From the Applications menu, select Enterprise Applications.
2. Select aveksa.
3. Stop the RSA Identity Governance and Lifecycle application if it is running.
4. Click Uninstall.

193
Procedure


IDC_ID
----------

(3, 7);
----------------------- ---- ------------------------- ---------
194
module
195
Maintaining a WebLogic Installation
l Accessing RSA Identity Governance and Lifecycle

l Stopping RSA Identity Governance and Lifecycle Services
l Starting and Stopping RSA Identity Governance and Lifecycle in WebLogic
l Restarting WebLogic
l Modifying the RSA Identity Governance and Lifecycle Enterprise Archive
l Check for Running Tasks in RSA Identity Governance and Lifecycle
l Localization Configuration
l Changing Database User Schema Names in RSA Identity Governance and Lifecycle
l Changing Database Tablespace Names in RSA Identity Governance and Lifecycle
l Changing Database User Passwords in RSA Identity Governance and Lifecycle
l Changing the Security Realm User and Group Information
l Uninstalling RSA Identity Governance and Lifecycle from WebLogic
l Updating RSA Identity Governance and Lifecycle on WebLogic with a Patch
Accessing RSA Identity Governance and Lifecycle

The WebLogic host where RSA Identity Governance and Lifecycle was installed (default_host in this example)
is typically available for HTTP on port 7001 for WebLogic, this may vary depending on your system. Contact
Unless there is a web proxy fronting the application server, you can access RSA Identity Governance and
Lifecycle using the following URL:
http://<machine>:7001/aveksa/main
Starting and Stopping RSA Identity Governance and Lifecycle in WebLogic

Use the WebLogic administrative console for all administrative task with RSA Identity Governance and Lifecycle.
Procedure
1. From the menu, select Deployments.
Aveksa should be listed as an installed application.
2. Select the checkbox beside the application and click the stop and start buttons to restart the application.
Restarting RSA Identity Governance and Lifecycle restarts the local agent as well.
Check for Running Tasks in RSA Identity Governance and Lifecycle

Before you upgrade RSA Identity Governance and Lifecycle, make sure there are no access governance tasks
running.
Procedure
2. Access the Monitoring feature under the Admin tab to determine whether tasks are running.
196
Restarting WebLogic
Use the WebLogic startWeblogic.sh script to start WebLogic, and use the stopWeblogic.sh script to stop
WebLogic. The scripts are located in the following directory:
$WEBLOGIC_HOME/user_projects/domains/aveksaDomain/bin
Modifying the RSA Identity Governance and Lifecycle Enterprise Archive

To modify RSA Identity Governance and Lifecycle, you must unzip the aveksa.ear and aveksa.war files, make
changes required for customization, and then re-zip the files before deploying or re-deploying them on
WebLogic.
Procedure
1. Set up a working directory, “new_ear” for example.
2. Copy the aveksa.ear file to the working directory.
3. Create a temporary ear directory, "ear_dir" for example, in the working directory.
4. Unzip aveksa.ear in the ear_dir directory:
cd ear_dir
jar -xvf ../aveksa.ear
5. Perform any required modifications within ear_dir.
For example, if you created your database instance with non-default names (for AVUSER, AVDWUSER,
etc) or non-default database tablespace names, then you need to edit Aveksa_System.cfg file to add the
appropriate values to the aveksa.ear.
6. Rebuild the modified aveksa.ear:
cd ear_dir
jar uvfm ../aveksa.ear META-INF/MANIFEST.MF *
The aveksa.ear in the working directory now has been updated with the changes. You can now specify
the path for your modified ear for deployment updates. For example:
new_ear/aveksa.ear
Configure a Non-SSL Port for WebLogic

Configure port 8080 if a non-SSL agent is installed on the same machine as the RSA Identity Governance and
Lifecycle application server. For example, port 8080 is used when an ITIM agent is installed on the RSA Identity
Governance and Lifecycle machine.
You do not need to open the port on any firewalls, but you must configure the port as described in this task.
In a clustered, perform this task for each server.
Procedure
2. Select Environment > servers.
3. For each server where RSA Identity Governance and Lifecycle is installed, click the server name and go
to Protocol Tab > Channels > New.
197

l Name: Aveksa8080
l Protocol: http
l Listen Address: 0.0.0.0 or (IPv6)
l Listen Port: 8080
l External Listen Port: 8080
Accept defaults for other settings.
Localization Configuration
RSA Identity Governance and Lifecycle can be localized to English, French, and German. By default, the RSA
Identity Governance and Lifecycle user interface is set to the language to which your internet browser is set.
This section describes how to create your own custom localization files for additional languages.
Procedure
1. Translate the contents of the following file to the language you want to provide as a localization option:
/strings.properties
2. Save the file in the following format:
/strings_XX.properties
where is XX is the ISO-639 code as two lowercase letters. For example:
Language Code Language

de German
fr French
ja Japanese
ko Korean
zh Chinese
3. Modify the Aveksa ear file with the additional localization file and then redeploy the file into the
application server and restart the server. See Modifying the Enterprise Archive for more information.
Note: Custom localization files are deleted when you upgrade system software. Therefore you must save any
files you create off the system before you upgrade. Also, you must update the translation as new strings are
introduced to the product between releases. Localization of online help is not currently supported.
Changing Database User Schema Names in RSA Identity Governance and

Lifecycle
This section describes how to change the RSA Identity Governance and Lifecycle database user schema names
for the following authentication users if the names in the database have changed:
198
Procedure
1. Open the aveksa.ear/aveksa.war/WEB-INF/Aveksa_System.cfg file for editing.
2. Replace the default (or previously specified non-default) name value with the names configured for the
database:
AVEKSA_USER=AVUSER
AVEKSA_REPORTS_USER=AVDWUSER
AVEKSA_PUBLIC_DB_USER=ACMDB
3. Modify and redeploy the Aveksa ear file with the changes you made to the Aveksa_System.cfg file. See
Modifying the Enterprise Archive for more information.
Changing Database Tablespace Names in RSA Identity Governance and Life-

cycle
This section describes how to change the database tablespace names used by RSA Identity Governance and
Lifecycle if non-default tablespace names are configured in the database used by RSA Identity Governance and
Lifecycle.
The well known default tablespace names are:
l DATA_256K
l DATA_1M
l DATA_25M
l DATA_50M
l INDX_256K
l INDX_1M
l INDX_25M
l INDX_50M
l DEFAULT_TABLESPACE
l TEMP_TABLESPACE
If non-default names are configured in the database, you must update the Aveksa_System.cfg file and modify
and redeploy the aveksa ear file.
Procedure
1. Open the aveksa.ear/aveksa.war/WEB-INF/Aveksa_System.cfg file.
2. Replace the default name with a non-default name as follows:
l DATA1_TABLESPACE=DATA_256K
l INDX1_TABLESPACE=INDX_256K
199
3. Designate a tablespace for the DEFAULT_TABLESPACE variable and, optionally, one for the TEMP_
TABLESPACE variable:
l DEFAULT_TABLESPACE= DATA_1M
l TEMP_TABLESPACE=TEMP
If, for example, you created 2 tablespaces for indexes (small, large) and 2 Tablespaces for data (small,
large) you might have an Aveksa_System.cfg that looks like this:
l DEFAULT_TABLESPACE=ACM_DATA_LARGE
4. Save and close the aveksa.ear/aveksa.war/WEB-INF/Aveksa_System.cfg file.
Modify and deploy the aveksa.ear file application server. See Modifying the Enterprise Archive for more
information.
Changing Database User Passwords in RSA Identity Governance and Life-

cycle
This section describes how to change the RSA Identity Governance and Lifecycle database user passwords for
the following authentication users if the passwords for the users are changed in the database:
l AVUSER
l AVDWUSER
l ACMDB
Procedure
1. Edit a JDBC data source for AVDB (Services > Data Sources).
2. Click the data source.
3. From Configuration, select the Connection Pool tab.
4. Edit the Password field with the new password.
RSA recommends that you then test the connections for the JDBC data sources.
Changing the Security Realm User and Group Information

If you change security realm user and group information, you must also modify the RSA Identity Governance
and Lifecycle EAR and redeploy the EAR as described in Modifying the Enterprise Archive.
200
Once you have changed security realm settings (as described in Create Security Realm Users and Groups) and
exploded the EAR, you can change a user’s password and change the principle user. All changes you make to
files in the EAR must match those made to security realm settings.
Procedure
1. Open the hibernate-cfg.xml file that is located in the aveksa.war/WEB-INF directory path.
2. Replace the principle user value, “aveksaUser” and the default principle user password, “Aveksa123,”
with the new values you specified for the security realm in the following lines:
<property name="hibernate.jndi.java.naming.security.principal">aveksaUser</property>
<property name="hibernate.jndi.java.naming.security.credentials">Aveksa123</property>
3. Save your changes to hibernate-cfg.xml.

4. Open the weblogic.xml file that is located in the aveksa.war/WEB-INF directory path.
5. Change the principle user value from “aveksaUser” to the user you have defined in your security realm.
<run-as-role-assignment>
<role-name>acmUsers</role-name>
<run-as-principal-name>aveksaUser</run-as-principal-name>
</run-as-role-assignment>
6. Save your changes to weblogic.xml.

7. Recreate the RSA Identity Governance and Lifecycle EAR and redeploy the EAR.
Updating RSA Identity Governance and Lifecycle on WebLogic with a Patch

A patch is an interim release of an RSA Identity Governance and Lifecycle version that addresses a specific
customer requirement. Patches undergo limited testing and should only be applied to address specific
requirements. RSA recommends that you back up the database before installing a patch. Consult
support@aveksa.com for questions about patches. Patches are available from RSA SecurCare Online at
https://knowledge.rsasecurity.com.
A patch is version specific, that is, it can only be installed on the base version for which it was developed. For
example, you cannot update product version X with a version Y patch without first installing version Y. Also,
patches are cumulative, that is, they include all fixes included in previous patches. For example, if P02 (patch
version 02) was previously installed you can install P05 without having to first install P03 and P04. RSA
recommends that you do not attempt to install a previous version of a patch over a later version of a patch.
Procedure
1. Download the following files from RSA SecureCare Online:
l PatchInfo.txt: Contains information on the fixes provided by the patch and any prerequisites that
must be met before you install it.
l Patch_<version>_Release_Notes.pdf
l ACM-WebLogic-<product version>_P0<version number>.tar.gz
2. Uncompress and untar the ACM-WebLogic-<product version>_P0<version number>.tar.gz file. This

extracts the ear file to be deployed: aveksa.ear
Follow the instructions in the Upgrade and Migration Guide to deploy the ear file. This involves a full
201
install of the ear. Any modifications made in your installation will also need to be made to the hotfix ear
before deployment. See Modifying the Enterprise Archive for more information.
Uninstalling RSA Identity Governance and Lifecycle from WebLogic

This section describes how to uninstall RSA Identity Governance and Lifecycle as required.
Procedure
1. Open the Administrative Console.
2. Go to Deployments, and select aveksa.
3. Stop the aveksa application if it is running.
4. Click Delete.

Procedure

202

IDC_ID
----------

(3, 7);
----------------------- ---- ------------------------- ---------
module
Uninstall AFX using the Uninstall Script
This procedure describes how to uninstall AFX from an appliance or software bundle server using the uninstall
script. You might perform this procedure if the installation process fails on an RSA appliance or on a Software
Bundle server where RSA Identity Governance and Lifecycle is installed.
Note: RSA recommends that you back up your data that may be lost during the uninstallation process. This
may include any localized files you have changed, keystores with installed certificates, or configuration files that
were modified.
203
Procedure
procedure may not work using a different account.
2. Stop the AFX server. For instructions, see Stop the AFX Server on page 127.
3. Navigate to the following directory:
cd <aveksa-staging-directory>/deploy/AFX-scripts/
./uninstallAFX.sh
You can check results of the uninstall process in the uninstall log file in the /tmp directory.
For example:
/tmp/afx-uninstall.log.Dec-21-2011.07.42.26
Uninstall AFX from an AFX Server Archive

This section describes how to uninstall the AFX Server on WebLogic or WebSphere or a remote AFX deployment
or on an RSA Identity Governance and Lifecycle host where you want to uninstall the local server which was
installed from a downloaded local AFX server archive.
Note: RSA recommends that you back up your data that may be lost during the uninstallation process. This
may include any localized files you have changed, keystores with installed certificates, or configuration files that
were modified.
Procedure
1. Log in to the AFX server using the afx account.
2. Stop the AFX server. For instructions, see Stop the AFX Server on page 127.
3. If the afx_server service is installed and configured, perform these steps to remove the afx_server
service. Otherwise, skip this step.
a. Log in as root to the AFX server.
b. Unregister the service:
chkconfig afx_server off
c. Remove the service:
chkconfig -del afx_server
d. Remove the link created for afx_server:
rm /etc/init.d/afx_server
4. Go to the afx account home directory and remove the AFX folder:
cd /home/afxuser
rm -rf AFX
204
Verify the Installation
After you complete the installation process, log in to the RSA Identity Governance and Lifecycle user interface
and check RSA Identity Governance and Lifecycle capabilities:
l Invoke various screens to ensure they are functioning properly.

l Run various tasks, such as collections, reviews, reports, and policies.
Note: If the installation failed and you must uninstall RSA Identity Governance and Lifecycle, see Uninstalling
for instructions.
205

IGL 7.2.1 Installation Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IGL 7.2.1 Installation Guide

Uploaded by

Copyright:

Available Formats

RSA Identity Governance and Lifecycle

Note on encryption technologies

Copyright © 2020 RSA Security LLC or its affiliates. All Rights Reserved.

About This Guide 12

Support and Service 12

Chapter 1: Installation Scenarios 13

Application Server Cluster Support for RSA Appliance and Software Bundle 13

Chapter 2: Installation Prerequisites 15

Supported Environments and Components 15

Remote Agent Requirements 15

Verify Prerequisites for a Customer-Supplied Database 16

Plan the Customer-Supplied Database Configuration 16

Verify Prerequisites for an RSA Appliance 17

RSA Appliance Components 17

Supplied Hardware Components 17

Supplied Software Components 17

Additional Required Hardware Components 18

Software Bundle Requirements 18

Hardware Requirements for the Software Bundle 18

Operating System Requirements for the Software Bundle 19

Customer-Supplied Database Requirements for the Software Bundle 20

Time Server Requirement for the Software Bundle 20

Virtual Application Requirements 20

Database Requirements for the Virtual Application 21

Time Server Requirement for the Virtual Application 21

Verify Prerequisites for WebSphere 21

Customer-Supplied Database Configuration for WebSphere Installations 22

WebSphere Application Server Requirements 22

Verify Prerequisites for WebLogic 23

Customer-Supplied Database Configuration for WebLogic Installations 23

WebLogic Application Server Requirements 24

Chapter 3: RSA Appliance Installation 25

Install the Appliance 25

Configure Appliance Network Settings 25

Log on to RSA Identity Governance and Lifecycle 27

Confirm the Setting for the Encryption Key Directory 28

Using Non-restrictive Mode for the Encryption Key Directory 30

Implement Security Best Practices 32

Step 1: Generate a Key Pair 32

Step 2: Generate a Certificate Signing Request 33

Step 3: Import a Trusted Certificate 34

Check Security Settings for RSA Identity Governance and Lifecycle 36

Setting Up User Access to RSA Identity Governance and Lifecycle 36

Chapter 4: Software Bundle Installation 37

Download the RSA Identity Governance and Lifecycle Installation Files 37

Before You Begin 37

Copy the Installation Files to the Installation Host 38

Perform the Installation 39

Perform the Installation as the Root User 40

Perform Installation as the Oracle User 42

Open Ports On the Firewall 43

Log on to RSA Identity Governance and Lifecycle 43

Apply the Latest Database Patch Updates to a Software Bundle 43

Confirm the Setting for the Encryption Key Directory 44

Using Non-restrictive Mode for the Encryption Key Directory 45

Implement Security Best Practices 47

Step 1: Generate a Key Pair 48

Step 2: Generate a Certificate Signing Request 49

Step 3: Import a Trusted Certificate 50

Check Security Settings for RSA Identity Governance and Lifecycle 52

Setting Up User Access to RSA Identity Governance and Lifecycle 52

Chapter 5: Virtual Application Installation 53

Set Up the Database for the Virtual Application 54

Set Up the RSA Identity Governance and Lifecycle Virtual Application 54