Installation UpgradeGuide

RSA Adaptive Authentication
(On-Premise) 7.1
Installation and Upgrade Guide
Contact Information
Go to the RSA corporate website for regional Customer Support telephone and fax numbers:
www.emc.com/domains/rsa/index.htm
Trademarks
RSA, the RSA Logo, BSAFE, eFraudNetwork, SecurCare and EMC are either registered trademarks or trademarks of EMC
Corporation in the United States and/or other countries. All other trademarks used herein are the property of their respective
owners. For a list of EMC trademarks, go to www.emc.com/legal/emc-corporation-trademarks.htm#rsa.
License Agreement
This software and the associated documentation are proprietary and confidential to EMC, 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 EMC.
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 EMC software described in this publication requires an applicable software license.
EMC 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." EMC CORPORATION 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 20132014 EMC Corporation. All Rights Reserved. Published in the USA.
July 2013
Revised: November 2013, March 2014
RSA Adaptive Authentication (On-Premise) 7.1 Installation and Upgrade Guide
Contents
Preface................................................................................................................................... 9
About This Guide................................................................................................................ 9
RSA Adaptive Authentication (On-Premise) Documentation ............................................ 9
Support and Service .......................................................................................................... 10
Before You Call Customer Support........................................................................... 10
Chapter 1: Prepare for Installation......................................................................11

General Recommendations ................................................................................................11
Database Sizing Guidelines ...............................................................................................11
File System Log Sizing ..................................................................................................... 12
Chapter 2: Installation Prerequisites ................................................................ 13

Installation Prerequisites for an Oracle Database ............................................................. 13
Installation Prerequisites for MS SQL Server................................................................... 15
Installation Prerequisites for Unix Operating Systems ..................................................... 16
Installation Prerequisites for WebSphere.......................................................................... 16
Installation Prerequisites for Tomcat ................................................................................ 17
Installation Prerequisites for BSafe................................................................................... 19
Installation Prerequisites for JBoss ................................................................................... 20
Installation Prerequisites for WebLogic ........................................................................... 22
Chapter 3: Install Adaptive Authentication (On-Premise) ................... 23

Installation Module ........................................................................................................... 23
Install Adaptive Authentication (On-Premise) ................................................................. 24
Provide Preliminary Information ............................................................................... 26
Define the Installation................................................................................................ 27
Configure the Core Database ..................................................................................... 28
Configure the Back Office Database ......................................................................... 33
Configure the Case Management Database ............................................................... 37
Configure the Core Applications ............................................................................... 42
Specify Connection Parameters for WebSphere........................................................ 42
Specify Connection Parameters for Tomcat .............................................................. 43
Specify Connection Parameters for WebLogic ......................................................... 44
Specify Connection Parameters for JBoss ................................................................. 45
Configure the Back Office Applications ................................................................... 45
Review the Installation Parameters............................................................................ 49
Review the Installation Summary.............................................................................. 49
Perform Post Installation Tasks ........................................................................................ 50
Deploy Web Applications.......................................................................................... 50
Replacing the Quartz Library in JBoss ...................................................................... 53
Configuring Parameters in the Administration Console............................................ 54
Copy External Data Provider Files ............................................................................ 54
Complete a Dry-Run Installation ...................................................................................... 55
Contents 3
Run SQL Scripts ........................................................................................................ 55

Add a Caller in the Web Services Credential Manager ............................................. 60
Set Up the Trusted Certificate for WebSphere .......................................................... 60
Test the Installation ........................................................................................................... 60
Check the Installation of Core Applications.............................................................. 60
Checking the Installation of Back Office Applications ............................................. 61
Uninstall Adaptive Authentication (On-Premise)............................................................. 62
Delete the Databases .................................................................................................. 62
Uninstall the Web Applications ................................................................................. 63
Delete Generated Files............................................................................................... 63
Chapter 4: Prepare to Upgrade ............................................................................ 65

Upgrade Prerequisites ....................................................................................................... 65
Prerequisites for MS SQL.......................................................................................... 68
Prerequisites for Oracle ............................................................................................. 68
Prerequisites for BSafe .............................................................................................. 69
Prerequisites for WebLogic ....................................................................................... 70
Prerequisites for JBoss............................................................................................... 71
Chapter 5: Upgrade from a Previous Version of Adaptive

Authentication (On-Premise) ................................................................................. 73
Overview of the Upgrade Module .................................................................................... 73
Installation Varfile ..................................................................................................... 74
Extract the Upgrade Module ............................................................................................. 74
Run the Upgrade Setup Process for Windows .................................................................. 75
Run the Upgrade Setup Process for Unix ......................................................................... 76
Provide Preliminary Information ...................................................................................... 78
Define the Upgrade ........................................................................................................... 79
Configure the Core Database ............................................................................................ 82
Configure the Core Database on Oracle .................................................................... 82
Configure the Core Database on MS SQL Server ..................................................... 83
Configure the Back Office Database ................................................................................ 84
Configure the Back Office Database on Oracle......................................................... 85
Configure the Back Office Database on MS SQL Server ......................................... 86
Configure the Case Management Database ...................................................................... 87
Configure the Case Management Database on Oracle .............................................. 87
Configure the Case Management Database on MS SQL Server ............................... 88
Configure the Core Applications ...................................................................................... 89
Specify Connection Parameters for WebSphere........................................................ 90
Specify Connection Parameters for Tomcat .............................................................. 90
Specify Connection Parameters for WebLogic ......................................................... 91
Specify Connection Parameters for JBoss ................................................................. 91
Configure the Back Office Applications........................................................................... 92
Specify Back Office Connection Parameters for WebSphere ................................... 92
Specify Back Office Connection Parameters for Tomcat.......................................... 92
4 Contents
Specify Back Office Connection Parameters for WebLogic ..................................... 93

Specify Back Office Connection Parameters for JBoss............................................. 94
Review the Upgrade Parameters and Activate the Upgrade ............................................. 94
Review the Upgrade Summary ......................................................................................... 95
Troubleshooting After the Upgrade .................................................................................. 95
Perform Post-Upgrade Tasks ............................................................................................ 97
Enable Partitions on an Oracle Database ................................................................... 97
Import Configuration Information into the Administration Console......................... 97
Integrate the Authentication Plug-In Information from the Backup.......................... 98
Set Encryption............................................................................................................ 99
Import Configurations to the Database ...................................................................... 99
Replace the Quartz Library in JBoss ......................................................................... 99
Upgrade Client-Side Components ........................................................................... 100
Update the deviceRecovery.drl File......................................................................... 100
Copy External Data Provider Files .......................................................................... 100
Enable Mobile Application Protection .................................................................... 100
Configure Authentify Settings ................................................................................. 100
Chapter 6: Complete a Dry-Run Upgrade ................................................... 103

Run SQL Scripts ............................................................................................................. 103
SQL Scripts for Oracle ............................................................................................ 104
SQL Scripts for MS SQL Server ............................................................................. 106
Deploy Web Applications............................................................................................... 108
Deploy Web Applications on Tomcat ..................................................................... 108
Deploy Web Applications on WebSphere ............................................................... 109
Deploy Web Applications on WebLogic..................................................................110
Deploy Web Application on JBoss ...........................................................................110
Tasks After Web Application deployment ...............................................................110
Check the Installation of Core Applications ....................................................................111
Check the Installation of Back Office Applications ........................................................111
Check the Database Upgrade ...........................................................................................112
Chapter 7: Configure Adaptive Authentication Applications ..........113

Configure the Core Applications .....................................................................................113
Configure the Adaptive Authentication Application ................................................113
Configure the Adaptive Authentication Administration Application.......................115
Configure the Scheduler ...........................................................................................116
Configure the Back Office Applications..........................................................................117
Configure the Access Management Application ......................................................117
Configure the Case Management Application..........................................................118
Configure the Back Office Application ....................................................................119
Configure the Report Viewer Application............................................................... 120
Configure the Web Service Credentials Manager Application ............................... 121
The Aggregator Token Application ......................................................................... 121
Configure the RSA Risk Engine ..................................................................................... 125
Contents 5
Configure a Separate Work Manager for RSA Risk Engine Offline Tasks.................... 125
Secure the Data Source Password for Tomcat ................................................................ 126
Change a Secure Database Password....................................................................... 127
Change the Encryption Scheme ............................................................................... 127
Configure the Web Services Author Application ........................................................... 129
Configure the log4j.properties File ................................................................................. 130
Shared Configuration Information in a Distributed Environment .................................. 131
Chapter 8: Install and Configure Maintenance Utilities ...................... 133

Batch Loader Utility........................................................................................................ 133
Install the Batch Loader Utility ............................................................................... 134
Configuring the Batch Loader Utility ............................................................................. 135
Configure the Batch Loader Utility to Run in Risk Engine Mode .......................... 136
Configure the Batch Loader Utility to Run in Full Mode........................................ 136
Fact Files.................................................................................................................. 137
Install the ConfigTool Utility.......................................................................................... 137
Configure the ConfigTool Utility ................................................................................... 140
Add a Configuration Tree to the Database .............................................................. 140
Export the Configuration Space Tree to a File ........................................................ 142
eFraudNetwork Agent..................................................................................................... 144
Configure eFraudNetwork Files...................................................................................... 145
Configure the efnagent-context.xml File ................................................................. 145
Test the Connectivity ............................................................................................... 146
Checking for Updates .............................................................................................. 147
Encryption Utility ........................................................................................................... 148
Switch to the New RSA Risk Engine Model .................................................................. 148
Roll Back to the Previous Risk Engine Model ............................................................... 149
Install the ws_auth_tool Utility....................................................................................... 149
Configuration Migration Tool......................................................................................... 150
Configure the Configuration Migration Tool .......................................................... 151
Chapter 9: Install and Configure Development Utilities ..................... 153

Install rsa-auth-plugin-tools ............................................................................................ 153
Install Updated Web Resources Files ............................................................................. 154
Prevent Caching of the Flash File by the Flash Player ............................................ 155
Appendix A: Set Up the Application Servers ............................................ 157

Set Up a Trusted Certificate............................................................................................ 157
Download the Trusted Certificate............................................................................ 157
Import the Trusted Certificate to the Java Truststore .............................................. 158
Setting Up WebSphere with Oracle ................................................................................ 158
Create a J2C Authentication Alias........................................................................... 159
Create a JDBC Data Source for Oracle ................................................................... 160
Test the Connection ................................................................................................. 163
Setting Up the BEA WebLogic Application Server ....................................................... 163
6 Contents
Appendix B: Support for Real Application Clusters ............................. 165

Changes Required to Support RAC Active/Active Configuration ................................. 165
Implement Risk Engine Offline Tasks on a RAC Configuration ................................... 166
Implement Adaptive Authentication (On-Premise) Online Activity on a RAC
Configuration ............................................................................................................... 166
Add Adaptive Authentication (On-Premise) RAC Support for a New RAC Node........ 167
Contents 7
Preface
About This Guide

This guide describes how to install, or upgrade to, RSA Adaptive Authentication
(On-Premise) 7.1. This guide is intended for project managers, system administrators,
database administrators, implementors, developers, and other trusted personnel. Do
not make this guide available to the general user population.
RSA Adaptive Authentication (On-Premise) Documentation

For more information about RSA Adaptive Authentication (On-Premise) 7.1, see the
following documentation:
Authentication Plug-In Developers Guide. Describes the Authentication Plug-In
development process that enables external authentication providers to integrate
their products with RSA Adaptive Authentication (On-Premise).
Back Office Users Guide. Provides an overview of the following Back Office
applications: Policy Management, Case Management, Access Management,
Customer Service Administration, and the Report Viewer.
Bait Credentials Setup and Implementation Guide. Describes how to set up and
implement RSA bait credentials, which help provide you with accelerated fraud
detection and prevention capabilities.
Best Practices for Challenge Questions. Describes the best practices related to
challenge questions that RSA has evolved through experience at multiple
deployments.
Installation and Upgrade Guide. Describes detailed procedures on how to install,
upgrade, and configure RSA Adaptive Authentication (On-Premise).
Integration Guide. Describes how to integrate and deploy RSA Adaptive
Authentication (On-Premise).
Operations Guide. Provides information on how to administer and operate
RSA Adaptive Authentication (On-Premise) after upgrade. This guide also
describes how to configure Adaptive Authentication (On-Premise) within the
Configuration Framework.
Performance Guide. Provides information about performance testing and
performance test results for the current release version of RSA Adaptive
Product Overview Guide. Provides a high-level overview of RSA Adaptive
Authentication (On-Premise), including system architecture.
Preface 9
Release Notes. Provides information about what is new and changed in this
release, as well as workarounds for known issues. It also includes the supported
platforms and work environments for platform certifications. The latest version of
the Release Notes is available on RSA SecurCare Online at
https://knowledge.rsasecurity.com.
Security Best Practices Guide. Provides recommendations for configuring your
network and RSA Adaptive Authentication (On-Premise) securely.
Web Services API Reference Guide. Describes RSA Adaptive Authentication
(On-Premise) Web Services API methods and parameters. This guide also
describes how to build your own Web Services clients and applications using Web
Services API to integrate and utilize the capabilities of Adaptive Authentication
(On-Premise).
Whats New. Highlights new features and enhancements in RSA Adaptive
Authentication (On-Premise) 7.1.
Workflows and Processes Guide. Describes the workflows and processes that
allow end users to interact with your system and that allow your system to interact
with RSA Adaptive Authentication (On-Premise).
Support and Service

RSA SecurCare Online https://knowledge.rsasecurity.com
Customer Support Information www.emc.com/support/rsa/index.htm
RSA Solution Gallery https://gallery.emc.com/community/marketplace/rsa?

view=overview
RSA SecurCare Online offers a knowledgebase that contains answers to common

questions and solutions to known problems. It also offers information on new releases,
important technical news, and software downloads.
The RSA Solution Gallery provides information about third-party hardware and
software products that have been certified to work with RSA products. The gallery
includes Secured by RSA Implementation Guides with step-by-step instructions and
other information about interoperation of RSA products with these third-party
products.
Before You Call Customer Support

Make sure that you have direct access to the computer running the Adaptive
Authentication (On-Premise) software.
Please have the following information available when you call:
Your RSA Customer/License ID.
Adaptive Authentication (On-Premise) software version number.
The make and model of the machine on which the problem occurs.
The name and version of the operating system under which the problem occurs.
10 Preface
1 Prepare for Installation

General Recommendations
Database Sizing Guidelines
File System Log Sizing
This chapter describes the recommendations to install RSA Adaptive Authentication
(On-Premise) 7.1.
General Recommendations
The following are the general recommendations for the installation:
Adaptive Authentication databases should be installed by a database administrator
(DBA).
Install the Core Database on a different server than the web applications.
Install the Core applications and Back Office applications on different servers.
Guidelines for database sizing are related to the size of the customer base. See the
recommendations in the following section, Database Sizing Guidelines.
Database Sizing Guidelines

Guidelines for database sizing are related to the size of the customer base. The
recommendations in this section apply to all databases and account for Data and Index
space requirements:
Scale your database storage according to the estimate that 1 million users require
approximately 32 to 35 gigabytes of space in the database, broken down per user
as follows:
Desktop25 kilobytes
Users6-7 Kilobytes
Bindings100 bytes
User Change History (UCH)50 bytes
Contacts150 bytes
Risk Engine Profiling Data3 kilobytes per user, 0.5 kilobytes per IP, 0.5
kilobytes per payee, other account, etc.
Risk Engine Data EventLog Table
1 kilobyte per login
1.6 kilobytes per transaction
1: Prepare for Installation 11

The following factors may require additional disk space:

Character set (single or double byte)
Type of backup mode
Frequency of hot backups
Duration of archive log preservation
Example
A daily hot backup with a record update requires 25 kilobytes per user. There are 1
million users signing in per day.
Calculation: 25 Kilobytes x 1 million=25 gigabytes of disk space for archive
logging per day, in addition to the backup of database files.
File System Log Sizing

Log size is almost entirely dependent upon the transaction volume passing
through the system.
Audit and forensic logs, in most cases, write out approximately 6 lines of data per
transaction in total (6 x ~100 Bytes/line=~0.6 Kilobytes).
The recommended formula for calculating audit and forensic log sizes is as
follows:
Log volume (KB/Day) = Transactions per day x 0.6
12 1: Prepare for Installation

2 Installation Prerequisites
Installation Prerequisites for an Oracle Database
Installation Prerequisites for MS SQL Server
Installation Prerequisites for WebSphere
Installation Prerequisites for Tomcat
Installation Prerequisites for BSafe
Installation Prerequisites for JBoss
Installation Prerequisites for WebLogic
This chapter describes requirements that you must satisfy before installing
RSA Adaptive Authentication (On-Premise) 7.1.
Installation Prerequisites for an Oracle Database

Ensure that you meet the following installation prerequisites for Oracle:
Install JRE version 1.6 or higher on the machine where the database setup
configuration script will run.
Make sure that an Oracle Instance exists for your database.
Make sure that you have an Oracle Database Listener up and running.
Make sure that you have access to Oracle SQL*Plus.
Make sure that you have a temporary tablespace (TEMP) for your database. In
most cases, a temporary tablespace is created by Oracle whenever a database is
created.
Use Type 4 JDBC drivers only.
Use the available JDBC Oracle thin drivers.
Oracle 10g: ojdbc14.jar
These .jar files are usually packaged with Oracle in the OraHome1/jdbc/lib
directory.
You must specify this driver file location in the Environment screen of the
Installation Module.
Note: You can download the driver from the following URL:
http://www.oracle.com/technology/software/index.html.
Create a new buffer cache. For instructions, see the following section Creating a
New Buffer Cache in Oracle.
2: Installation Prerequisites 13
If you need to install Oracle on Unix and you are not the Oracle instance user, do the
following:
1. Log on to the Unix machine as the Oracle software owner.
2. Verify that the ORACLE_HOME variable is set.
Setting a system variable in Unix differs depending on the Unix shell in which
you are working.
For example:
For sh or bash export ORACLE_HOME=oracle_home_dir
For csh or tcsh setenv ORACLE_HOME oracle_home_dir
For other Unix shells, consult your Unix documentation.
3. Make sure you have the required privileges on the instance directory. From the
Oracle instance user or root user, run the following command:
chmod -R 755 $ORACLE_HOME/*
4. Run the following commands before you begin the installation:
export ORACLE_HOME=Oracle_Home_full_path
export ORACLE_SID=Oracle_SID
Creating a New Buffer Cache in Oracle

The Core Database schema contains two BLOB columns that represent binary data
related to the users of the system. You can improve the performance of the main buffer
cache if you separate this binary data from the data in the main buffer pool. To do this,
you must create an additional buffer cache with a block size different from the block
size of the data tablespace.
To create a new buffer cache if the database uses an SPFILE:

1. Connect to the Oracle database as a privileged user. For example, System.
2. Run the following command:
alter system set db_<db blob tablespace block
size>k_cache_size=100M scope=both;
For example,
alter system set db_16k_cache_size=100M scope=both;
To create a new buffer cache if the database uses a PFILE:

1. Locate the initSID_Name.ora file, usually located in the $ORACLE_HOME/dbs
directory.
2. Add the following line to the initSID_Name.ora file:
db_<db blob tablespace block size>k_cache_size=100M
For example,
db_16k_cache_size=100M
3. Connect to the Oracle database with the SYSDBA-role user SYS.
14 2: Installation Prerequisites
4. Stop the database, as follows:

shutdown immediate
5. Start the database, as follows:
startup
Note: If you run the installation module without defining the BLOB tablespace block
size, you get the following error:
ORA-29339: tablespace block size 16384 does not match
configured block sizes
Installation Prerequisites for MS SQL Server

Ensure that you meet the following installation prerequisites for MS SQL Server:
Note: Make sure that SQL is installed on the machine from which you are running
the installer program if you are remotely installing the database.
Install JRE version 1.6 or higher on the machine where the database setup
configuration script will run.
Install SQL Server with Mixed Mode authentication. Do not use Windows Only
authentication.
Configure the SQL Server instance to use case-insensitive collation. This is the
default setting.
Download Microsoft SQL JDBC driver 1.2 or 2.0 (sqljdbc.jar or sqljdbc4.jar).
This driver is available from http://www.microsoft.com/downloads/.
The driver class name for SQL Server 2005 and SQL Server 2008 is
com.microsoft.sqlserver.jdbc.SQLServerDriver. You must specify this driver
file location in the Environment screen of the Installation Module.
Note: If you download the JDBC drivers from Microsoft, make sure that the
version and service pack match those of the installed MS SQL Server database.
Create a system administrator account to access the database. The account

credentials are required by the installation module.
Download JDK 1.6.0.
Important: Ensure that you have the latest build.
Installation Prerequisites for Unix Operating Systems

When running a UNIX-based operating system, such as AIX, Solaris, and Linux, on
your application server, you must limit the maximum number of files opened
simultaneously during processing.
To set the limit of simultaneously opened files:

Enter the following command in the same console window where you start the
application server:
ulimit -n 100000
Installation Prerequisites for WebSphere

Ensure that you meet the following installation prerequisites for WebSphere:
Install the latest WebSphere application server fix.
Ensure that the WebSphere server runs using the IBM JVM implementation.
Set the JAVA_HOME environment variable to point to the jre directory, as
follows:
On Windows:
set JAVA_HOME=IBM_WAS_HOME\AppServer\JRE_dir
On UNIX:
export JAVA_HOME=IBM_WAS_HOME/AppServer/JRE_dir
where:
IBM_WAS_HOME is the IBM WebSphere Home directory.
JRE_dir is the Java Runtime Environment directory that IBM WebSphere
uses. This is usually located under IBM_WAS_HOME/AppServer/java/jre
or IBM_WAS_HOME/AppServer/jre.
Set the JVM heap parameters, as follows:
a. Log on to the WebSphere Administrative Console.
b. Go to Servers > Application servers > application server name.
c. On the Configuration tab, in the Server Infrastructure area, select Java
and Process Management > Process Definition.
d. Under the Additional Properties section, click the Java Virtual Machine
link.
e. Under the General Properties section, enter the Initial Heap Size and
Maximum Heap Size memory allocations for your environment:
2560 for the initial and maximum heap size
f. Click Apply.
g. Click the Save link to save the changes to the master configuration.
h. Using the WebSphere Console, enter the values to configure the parameters as
listed in the following snippet:
-XX:MaxPermSize=512m
-Djavax.xml.transform.TransformerFactory=org.apache.
xalan.processor.TransformerFactoryImpl
-Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.
jaxp.SAXParserFactoryImpl
-Djavax.xml.parsers.DocumentBuilderFactory=org.apache.
xerces.jaxp.DocumentBuilderFactoryImpl
-Dorg.apache.xerces.xni.parser.XMLParserConfiguration=
org.apache.xerces.parsers.XML11Configuration
The WebSphere application server enforces the highest isolation level supported
by the database. For MS SQL databases, the highest isolation level supported is
TRANSACTION_REPEATABLE_READ (4), which can cause escalation locks.
To avoid this, you must lower the isolation level by resetting the
webSphereDefaultIsolationLevel property of the datasource to
TRANSACTION_READ_COMMITTED (2).
For instructions about adding the custom property for a data source using the
WebSphere Administrative Console, go to
http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg21224492.
For MS SQL databases only, to ensure the database supports the non-Unicode
character set, for example, Chinese, open the WebSphere Administrative Console.
Under Resources > Data sources > custom properties >
sendStringParametersAsunicode , change the value to True and restart the
server.
Installation Prerequisites for Tomcat

Ensure that you meet the following installation prerequisites for Tomcat:
Install Sun JRE 1.6. (Sun JDK 1.6.0_31 or higher)
Set the JAVA_HOME environment variable.
For UNIX installations, do the following:
Locate the java.security file in the path_to_JRE/lib/security directory and
open it for editing.
Locate the following line:
securerandom.source=file:/dev/urandom
and change it, as follows:
securerandom.source=file:/dev/random
Locate the section that looks similar to the following:

security.provider.1=sun.security.pkcs11.SunPKCS11
${java.home}/lib/security/sunpkcs11-solaris.cfg
security.provider.2=sun.security.provider.Sun
security.provider.3=sun.security.rsa.SunRsaSign
security.provider.4=com.sun.net.ssl.internal.ssl.Provi
der
security.provider.5=com.sun.crypto.provider.SunJCE
security.provider.6=sun.security.jgss.SunProvider
security.provider.7=com.sun.security.sasl.Provider
security.provider.8=org.jcp.xml.dsig.internal.dom.XMLD
SigRI
security.provider.9=sun.security.smartcardio.SunPCSC
Move the SunPKCS11 security provider to the end of the list and renumber, as
follows:
der
SigRI
Define the Java properties for Tomcat.
a. On Windows, click Start > Programs > Apache Tomcat version >
Configure Tomcat.
b. Under the Java tab, in the Java Options pane, define the following
properties:
-XX:PermSize=512m
-XX:MaxPermSize=512m
c. In the Initial Memory Pool field, enter 2048 MB.
d. In the Maximum Memory Pool field, enter 2048 MB.
Note: Make sure the Tomcat Manager and Admin applications are installed.
For Unix, configure the Java memory settings in the JAVA_OPTS variable in the
tomcat-home/bin/catalina.sh file, as follows:
JAVA_OPTS="-Xms1024m -Xmx2048m -XX:MaxPermSize=512m"
Copy the JDBC driver to Tomcat Home/lib and to the machine assigned to run the
installation module.
Installation Prerequisites for BSafe

You must apply a patch to avoid getting a security exception on the Sun or IBM JDK.
The java.security.InvalidKeyException:illegal Key Size error is a common issue
that occurs when you try to invoke a secured web service in an environment where the
provision for java unlimited security jurisdiction is not available. You may also see
errors related to java.security.NoSuchAlgorithmException. You can avoid these
exceptions by installing Java Cryptography Extension (JCE) unlimited strength
jurisdiction policy files.
To apply the patch:

1. Download the Java Cryptography Extension (JCE) Unlimited Strength
Jurisdiction Policy Files for your JDK version, as shown in the following table.
JDK Version Procedure
JDK 1.6 1. Go to
http://www.oracle.com/technetwork/java/javase/downloads/jce
-6-download-429243.html.
2. Download jce_policy-6.zip.
IBM JDK 6 1. Go to
https://www14.software.ibm.com/webapp/iwm/web/preLogin.d
o?source=jcesdk
2. Click the link under IBM SDK Policy files.
3. Log in to the Unrestricted JCE policy files site using your IBM
credentials.
4. Select Unrestricted JCE Policy files for SDK for all newer
versions (Version 1.6).
5. Click Continue, and then click Download now to download the
zip file.
BEA JDK 1. Go to
https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-C
DS_Developer-Site/en_US/-/USD/ViewProductDetail-Start?Pr
oductRef=jce_policy-1.5.0-oth-JPR@CDS-CDS_Developer.
2. Download jce_policy-1_5_0.zip.
2. Extract the local_policy.jar and US_export_policy.jar files in the zip file to the
$JAVA_HOME/jre/lib/security directory.
These files already exist in this directory. You must overwrite them.
3. Restart the application server, and re-invoke the secured service.
The invalidkeyException does not occur.
Installation Prerequisites for JBoss

Before upgrading to RSA Adaptive Authentication (On-Premise) 7.1 on JBoss, you
must do the following:
Copy the ehcache-core-2.3.0.jar file from the lib directory of any of the Adaptive
Authentication or Back Office applications to the
JBOSS_HOME/server/default/lib directory.
Copy the JDBC drivers to the JBOSS_HOME\server\default\lib directory.
Configure the JVM memory settings in the JBOSS_HOME\bin\run.conf.bat file
to suit your deployment. The following is the minimum setting for JDK on
Windows:
set "JAVA_OPTS=-Xms1024m -Xmx1024m -XX:PermSize=512m
-XX:MaxPermSize=1024m"
Create a file named aaop-ds.xml in the JBOSS_HOME\server\default\deploy
directory and copy the following code snippet into the aaop-ds.xml file:
<?xml version="1.0" encoding="UTF-8"?>
<datasources>
<local-tx-datasource>
<jndi-name>jdbc/PassMarkDB</jndi-name>
<connection-url>connection_url</connection-url>
<driver-class>JDBC_driver_class</driver-class>
<user-name>core_db_user_name</user-name>
<password>core_db_password</password>
</local-tx-datasource>
<jndi-name>jdbc/PassmarkToolDB</jndi-name>
<user-name>backoffice_db_user_name</user-name>
<password>backoffice_db_user_password</password>
<jndi-name>jdbc/CMDB</jndi-name>
<user-name>cm_db_user_name</user-name>
<password>cm_db_password</password>
</datasources>
Disable the CachedConnectionManager for the web server.

Disable JSP pooling.
To disable the CachedConnectionManager for the web server:

1. Navigate to JBOSS_HOME\server\default\deploy\jbossweb.sar.
2. Open the server.xml file, and comment the following element:
<Valve
className="org.jboss.web.tomcat.service.jca.CachedConnect
ionValve"
cachedConnectionManagerObjectName="jboss.jca:service=Cach
edConnectionManager"
transactionManagerObjectName="jboss:service=TransactionMa
nager" />
To disable JSP pooling:

1. Navigate to JBOSS_HOME\server\default\deployers\jbossweb.deployer:
2. Open the web.xml file, add an enablePooling init parameter, and set it to false,
as shown in the following snippet.
<init-param>
<param-name>enablePooling</param-name>
<param-value>false</param-value>
</init-param>
Note: This change is mandatory for the JBoss server that hosts the Back Office
applications.
Adding a Separate Thread Pool for the Risk Engine

On JBoss, you must add a separate thread pool in the
JBOSS_HOME\server\default\deploy\jca-jboss-beans.xml file for offline tasks.
For more information, see Configure a Separate Work Manager for RSA Risk Engine
Offline Tasks on page 125.
Installation Prerequisites for WebLogic

The supported versions for installation of RSA Adaptive Authentication
(On-Premise) 7.1 are Weblogic 10.3.x, where x is between 0 and 6.
Due to known issues in the WebLogic application server, you must download and
apply Patch 8176461 to WebLogic 10.3.x.
Edit the WebLogic startup script file as follows:
a. Depending on your platform, do one of the following:
In Windows, locate the startWebLogic.cmd file.
In Linux or Unix, locate the startWebLogic.sh file.
b. Locate the "set CLASSPATH" statement.
c. Verify that the javax.persistence_1.0.0.0_2-0-0.jar is listed first in the
classpath. For example, if Weblogic is installed in the c:\Oracle\Middleware
directory, the entry should appear as follows:
set
CLASSPATH=c:\Oracle\Middleware\modules\javax.persisten
ce_1.0.0.0_2-0-0.jar;%SAVE_CLASSPATH%
Edit PermSize parameters in the Java parameters, as follows:
a. Depending on your platform, do one of the following:
In Windows, in the <AAOP_DOMAIN> directory, locate the
/bin/setDomainEnv.cmd file.
In Linux or Unix, in the <AAOP_DOMAIN> directory, locate the
/bin/setDomainEnv.sh file.
b. Locate the following lines:
MEM_PERM_SIZE_64BIT="-XX:PermSize=128m"
export MEM_PERM_SIZE_64BIT
and edit the lines as follows:
MEM_PERM_SIZE_64BIT="-XX:PermSize=512m"
export MEM_PERM_SIZE_64BIT
c. Locate the following lines:
MEM_MAX_PERM_SIZE_64BIT="-XX:MaxPermSize=256m"
export MEM_MAX_PERM_SIZE_64BIT
and edit the lines as follows:
MEM_MAX_PERM_SIZE_64BIT="-XX:MaxPermSize=1024m"
export MEM_MAX_PERM_SIZE_64BIT
3 Install Adaptive Authentication

(On-Premise)
Installation Module
Install Adaptive Authentication (On-Premise)
Perform Post Installation Tasks
Complete a Dry-Run Installation
Test the Installation
Uninstall Adaptive Authentication (On-Premise)
This chapter describes how to install RSA Adaptive Authentication (On-Premise) 7.1,
using the installation module.
Installation Module
The RSA Adaptive Authentication (On-Premise) CD contains the artifacts to install,
upgrade, and configure components in the Adaptive Authentication application
system.
The RSA Adaptive Authentication (On-Premise) 7.1 installation packet includes .zip
files for each of the platforms supported by Adaptive Authentication.
To extract the installation module:

1. Choose the .zip file appropriate for your organization platform from the following
list:
AA-OnPrem.7.1.0.0.0.Unix.Installer.zip - for a Unix platform
AA-OnPrem.7.1.0.0.0.64_bit.Installer.zip - for Windows 64-bit platform
2. Copy the .zip file from the CD to the machine on which you plan to install
Adaptive Authentication (On-Premise) 7.1.
3. Unzip the .zip file.
The .zip file contains the following folders:
Installation. Contains artifacts to install and configure components in the
Adaptive Authentication system.
External-Data-Providers. Contains GeoIP and channel determination
data.
3: Install Adaptive Authentication (On-Premise) 23

The Installation directory contains the following files to install Adaptive

AA-OnPrem.7.1.0.0.0.Unix.Installer.sh - to install on a Unix platform
AA-OnPrem.7.1.0.0.0.64_bit.Installer.exe - to install on a Windows 64-bit
platform
Note: RSA recommends that you install Adaptive Authentication on its own
application server. If the application server includes other software, you might
encounter an overload on your thread pool.
Install Adaptive Authentication (On-Premise)

The Installation Module is a wizard (installer program) that configures and deploys
the different Adaptive Authentication components according to your input. During the
installation process, you must select the components that you want to install and
provide inputs for their configurations.
Note: The installer program creates a log file of the installation run environment and
all the installation actions. While the installer program is running, a log file named
i4j_log_aaop_<i4j generated number>.log is created in the temp directory. A file
named install.log is copied to the directory where the executable is available after the
installer program finishes running.
If the installer program shows an error message, copy the log file from the temp
directory to the directory of the executable, so that it is available for investigating the
problem.
Installation Varfile
At the end of the installation process, the installation module saves all of the inputs
required during the process in the installation variable file. The name of the variable
file is the same as that of the installation executable file, but with the extension
.varfile. This .varfile is created in the same folder as the installation module. It is also
copied for backup to the main folder used by Adaptive Authentication.
Important: Save the .varfile for later use. The .varfile can be useful if you want to
rerun the installation module or if you want to apply hot fixes or upgrades.
When the installation module is executed with the .varfile in the same folder, it
populates the fields in the wizard with values from the .varfile.
Note: Passwords are saved encrypted to the .varfile. If this poses a security risk, you
must manually remove the encrypted password values from the .varfile in both
locations.
24 3: Install Adaptive Authentication (On-Premise)

To run the installation module on Windows:

1. Change to the Installation directory where the installer program is located.
2. Double-click the AA-OnPrem.7.1.0.0.0.64_bit.Installer.exe file.
The installation setup begins. A progress bar indicates the progress of the setup.
To run the installation module at the command prompt on Windows:

2. Type the following command at the command prompt:
start /w AA-OnPrem.7.1.0.0.0.64_bit.Installer.exe
arguments
where arguments can be one of the following:
- c: Runs the installer program in console mode
- q: Runs the installer program in unattended mode. This argument should be
used with - varfile
- varfile installer-responses-file: Reads the responses from a file
The installation setup begins. A progress bar indicates the progress of the setup.
To run the installation module on UNIX:
Note: If you use FTP, sFTP, or SCP to send the installation module files across a
network, use binary transfer mode for the files.

2. Ensure that the installation script has execute permission. To set the permission,
type:
chmod u+x AA-OnPrem.7.1.0.0.0.Unix.Installer.sh
3. Run the following command:
./AA-OnPrem.7.1.0.0.0.Unix.Installer.sh arguments
- c: Runs the installer program in console mode
- q: Runs the installer program in unattended mode. This argument should be
used with - varfile
- varfile installer-responses-file: Reads the responses from a file
The installation setup begins.

On some Unix machines, the following error message appears when you run the
installation module using the -c option:
testing JVM in /usr ...
Starting Installer ...
Could not display the GUI. This application needs access to an X
Server.
*****************
If you have access there is probably an X library missing.You
can also run this application in console mode without access to
an X server by passing the argument -c
*****************
An error occurred:
java.awt.AWTError: Assistive Technology not found:
org.GNOME.Accessibility.JavaBridge
Error log: /var/tmp/install4jError20776.log
*****************
To resolve this issue, perform the following actions:
1. Log on as the root user.
2. Edit the /usr/java/jre/lib/accessibility.properties file where /usr/java/jre is the
directory in which the JRE is installed on your machine.
3. Comment out the property assistive_technologies.
4. Save the file and log out.
5. Rerun the installation module stating explicitly not to use graphics, as shown:
./AA-OnPrem.7.1.0.0.0.Unix.Installer.sh -c
-Dinstall4j.nolaf=true
This command runs the installation module without graphics. You can still use a
response file with this command.
Provide Preliminary Information
Important: All fields are mandatory unless stated otherwise. The values displayed in
the figures in this guide are not a recommendation.
1. Read the information on the Welcome screen.

2. Click Next.
3. If you agree with the terms of the License Agreement, select I accept the
agreement.
Note: If you select I dont accept the agreement, you cannot continue with the
installation.
4. Click Next.
The Environment Preparation Reminder screen appears.
5. Ensure that you meet the requirements specified in Chapter 2, Installation
Prerequisites and click Next.

6. On the Customer Information screen, in the Customer Name field, provide a

customer name for billing purposes.
7. Click Next.
Define the Installation

On the Installation Types screen, you select an installation type.
To define the installation:

1. Select the installation type that best suits your requirements.
Installation Type Description
Full Recommended. Installs all components including the

databases, core applications, Back Office applications,
development utilities, and maintenance utilities.
Databases Installs only the databases (Core Database, Back Office

Database, and Case Management Database).
Core Applications Installs only the core applications (Adaptive

Authentication, Adaptive Authentication Admin, and the
Scheduler). The databases must already be installed.
Back Office Applications Installs only the Back Office applications. The databases
and core applications must already be installed.
Note: The Policy Manager and Customer Service

applications are installed as part of the Administration
Console component.
Maintenance Utilities For system administrators. Installs only the maintenance

utilities.
Note: For more information, see Chapter 8, Install and

Configure Maintenance Utilities.
Development Utilities For developers. Installs only the development utilities.

Configure Development Utilities.
Custom Installation Installs only selected components.
Important: When running the installation process in command line mode, choose
Custom Installation for the installation type. Select the specific components
(applications) required for the installation.

2. Click Next.
On the Installation Components screen, you select the components for installation.
You can change the default selections.
Note: Depending on the components that you choose to install on the Installation
Components screen, the options available on the following screens will vary.
3. Click Next.
On the Environment screen, you define the environment for the installation.
4. In the Database Type section, select the database.
Once you select the database type, the JDBC Driver field is populated.
5. In the JDBC Driver File field, enter the path to the JDBC driver file. For
example, sqljdbc.jar in the case of MS SQL Server.
6. In the Application Server section, select the application server.
7. In the Main Directory field, specify the main directory where the logs, core
application configuration files, and reports are stored.
8. Click Next.
Configure the Core Database

On the Core Database screens, provide parameters required by the Core Database. On
the first Core Database screen, provide connection parameters.
You can choose to do a dry-run of the installation. A dry run is a testing process where
the effects of a possible failure are intentionally mitigated. In this case, you need not
run the SQL scripts during the installation. After the installation is complete, you can
manually run the SQL scripts, as described in Run SQL Scripts on page 55.
Note: If you are using a Tomcat application server, and are concerned about your
database passwords being stored in clear text in the Tomcat server.xml file, see Secure
the Data Source Password for Tomcat on page 126.
If you choose to install the databases, the relevant logs are created as *.log files in the
directory where the executable is available. You must attach the log files when you
contact RSA Support about an installation problem.
This section contains the following topics:
Configure the Core Database on Oracle
Configure the Core Database on MS SQL Server

To configure the Core Database on Oracle:

1. In the Core Database Setup section, select one of the options described in the
following table.
Option Description
Create a new database If you select this option, a new schema is

created. This is the default option.
Use newly created database Select this option if the database

administrator has created a schema and the
tablespaces on your system for use by the
core applications.
2. Select Run the SQL scripts if you want the installation module to run the SQL
scripts during installation.
If you do not select this option, the SQL scripts are configured with the database
parameters but are not run. You must manually run the SQL scripts following
installation. For more information, see Complete a Dry-Run Installation on
page 55.
3. In the Core Database Properties section, enter the values as described in the
following table.
Field Entry Description
Host Host name or IP address of the host server used by the

Core Database
Port Listening port for the Core Database
Name (SID) Database system ID (SID) of the host where the Core
Database resides
Alias Name (TNS) TNS name of the Core Database
Data Tablespace Name Name of the data tablespace
Index Tablespace Name Name of the index tablespace
BLOB Tablespace Name Name of the BLOB tablespace
4. In the Partitions section, select Enable Partitions if you want to enable partitions
for the Core Database.

5. In the Core Database Credentials section, enter the values as described in the
following table.
Schema Owner User name of the schema owner
Schema Password Password of the schema owner
Core Applications Username User name for the core applications
Core Applications Password Password for the core applications
Note: Ensure that the password you enter complies with your company and
database password policies.
6. Click Next.
To specify creation parameters for the Core Database on Oracle:

1. Complete the fields on the Core Database screen, as shown in the following table.
Administrator Username User name of the database administrator
Administrator Password Password of the database administrator
Data Tablespace Path Path to the data tablespace file
Data Tablespace File Size Size (in MB) of the data tablespace file
Data Tablespace File The maximum amount (in MB) the data tablespace file is
Growth allowed to increase in size when additional space is
required
Index Tablespace Path Path to the index tablespace file
Index Tablespace File Size (in MB) of the index tablespace file
Size
Index Tablespace File The maximum amount (in MB) the index tablespace file is
required
BLOB Tablespace Path Path to the BLOB tablespace file
BLOB Tablespace File Size (in MB) of the BLOB tablespace file
Size
BLOB Tablespace File The maximum amount (in MB) the BLOB tablespace file
Growth is allowed to increase in size when additional space is
required

BLOB Tablespace Block Block size of the new buffer cache. For more information,
Size see Creating a New Buffer Cache in Oracle on page 14.
2. Click Next.
To configure the Back Office Database on Oracle, see Configure the Back Office
Database on Oracle on page 33.

On the first Core Database screen, enter the connection parameters for the Core
Database on MS SQL Server.
To configure the Core Database on MS SQL Server:

1. In the Core Database Setup section, select one of the options described in the
following table.
Option Description
Create a new database If you select this option, the Core Database is
created. This option is selected by default.
Use an existing database Select this option if the database

administrator has created a schema and
core applications.
2. Select Run the sql scripts if you want the installation module to run the SQL
If you do not select this option, the SQL scripts will be configured with the
database parameters but will not be run. You must manually run the SQL scripts.
For more information, see Complete a Dry-Run Installation on page 55.
3. In the Core Database Properties section, enter the values, as described in the
following table.
Host Host name or IP address of the host server used by the Core Database
Instance Core Database instance
Note: Make an entry in this field only if you are not using the default
instance.
Name Name of the Core Database

Schema Name of the Core Database schema
Note: The dbo (default) schema must be used. You cannot edit the default
entry.
4. Enter the credentials for the Core Database, as described in the following table.
Administrator Username User name for the Core Database administrator
Administrator Password Password for the Core Database administrator
5. Enter the application user credentials for the Core applications as described in the
following table. The application user credentials are used by the web applications
to connect to the Core Database.
6. Click Next.
On the second Core Database screen, enter the creation parameters for the Core
To specify creation parameters for the Core Database on MS SQL Server:

1. In the Data File section, complete the fields as described in the following table.
Directory Path to the directory of the Core Database files.
Note: Ensure that this directory exists. The installation module does not
create this directory.
Name Name of the data file for the Core Database
Size Size (in MB) of the data file for the Core Database
Growth The maximum amount (in MB) the data file is allowed to increase in size
when additional space is required

2. In the Log File section, complete the fields as described in the following table.
Directory Path to the directory of the log files.
Name Name of the log file for the Core Database
Size Size (in MB) of the log file for the Core Database
Growth The maximum amount (in MB) the log file for the Core Database is
allowed to increase in size when additional space is required
3. Click Next.
To configure the Back Office Database on MS SQL Server, see Configure the Back
Office Database on MS SQL Server on page 35.
Configure the Back Office Database

On the Back Office Database screens, you provide parameters required by the Back
Office Database.
Important: If you are using a Tomcat application server, and are concerned about your
database passwords being stored in clear text in the Tomcat server.xml file, see Secure
the Data Source Password for Tomcat on page 126.

Configure the Back Office Database on Oracle
Configure the Back Office Database on MS SQL Server

On the first Back Office Database screen, enter the connection parameters for the
Back Office Database on Oracle.
To configure the Back Office Database on Oracle:

1. In the Back Office Database Setup section, select one of the options described in
the following table.
Option Description


Option Description

core applications.
parameters but are not run. You must manually run the SQL scripts. For more
information, see Complete a Dry-Run Installation on page 55.
3. In the Back Office Database Properties section, enter the values as described in

Back Office Database
Port Listening port for the Back Office Database
Name (SID) Database system ID (SID) of the host where the Back
Office Database resides
Alias Name (TNS) TNS name of the Back Office Database
4. In the Back Office Database Credentials section, enter the values as described in
Back Office Applications Username User name for the Back Office applications
Back Office Applications Password Password for the Back Office applications
5. Click Next.
On the second Back Office Database screen, enter the creation parameters for the
Back Office Database on Oracle.

To specify creation parameters for the Back Office Database on Oracle:

1. Complete the fields on the Back Office Database screen, as shown in the
following table.
Data Tablespace File Size Size (in MB) of the data tablespace file
Data Tablespace File The maximum amount (in MB) the data tablespace file is
required
Index Tablespace File Size (in MB) of the index tablespace file
Size
Index Tablespace File The maximum amount (in MB) the index tablespace file is
growth allowed to increase in size when additional space is
required
2. Click Next.
To configure the Case Management Database on Oracle, see Configure the Case
Management Database on Oracle on page 38.

On the first Back Office Database screen enter the connection parameters for the Back
Office Database on MS SQL Server.
To configure the Back Office Database on MS SQL Server:

1. In the Back Office Database Setup section, select one of the options described in
Option Description
Create a new database If you select this option, a new database is


core applications.

If you do not select this option, the SQL scripts will be configured with the
database parameters but will not be run. You must manually run the SQL scripts.
For more information, see Complete a Dry-Run Installation on page 55.
3. In the Back Office Database Properties section, complete the fields as described
in the following table.
Host Host name or IP address of the host server used by the Back Office
Database
Port listening port for the Back Office Database
Instance Back Office Database instance

This is an optional field
Name Name of the Back Office Database
Schema Name of the Back Office Database schema
entry.
4. Enter the credentials for the Back Office Database as described in the following
table.
Administrator Username User name for the Back Office Database administrator
Administrator Password Password for the Back Office Database administrator
5. Enter the application user credentials for the Back Office applications, as
described in the following table. The application user credentials are used by the
web applications to connect to the Back Office Database.
6. Click Next.
On the second Back Office Database screen, enter the creation parameters for the
Back Office Database on MS SQL Server.

To specify creation parameters for the Back Office Database on MS SQL Server:
Directory Path to the directory of the Back Office Database files.
Name Name of the data file for the Back Office Database
Size Size (in MB) of the data file for the Back Office Database
Name Name of the log file for the Back Office Database
Size Size (in MB) of the log file for the Back Office Database
Growth The maximum amount (in MB) the log file for the Back Office Database
is allowed to increase in size when additional space is required
3. Click Next.
To configure the Case Management Database on MS SQL Server, see Configure the
Case Management Database on MS SQL Server on page 40.
Configure the Case Management Database

On the Case Management Database screens, you provide parameters required by the
Case Management Database.
Configure the Case Management Database on Oracle
Configure the Case Management Database on MS SQL Server


On the first Case Management Database screen, enter the connection parameters for
the Case Management Database on Oracle.
To configure the Case Management Database on Oracle:

1. In the Case Management Database Setup section, select one of the options
described in the following table.
Option Description


core applications.
3. In the Case Management Database Properties section, enter the values as

Case Management Database
Port Listening port for the Case Management Database
Name (SID) Database system ID (SID) of the host where the Case
Management Database is running
Alias Name (TNS) TNS name of the Case Management Database
4. In the Case Management Database Credentials section, enter the values as


Case Management User name for the Case Management applications

Applications Username
Case Management Password for the Case Management applications

Applications Password
5. Click Next.
On the second Case Management Database screen, enter the creation parameters for
the Case Management Database on Oracle.
To specify creation parameters for the Case Management Database on Oracle:

1. Complete the fields on the Case Management Database screen, as shown in the
following table.
Data Tablespace File Size Size of the data tablespace file
Data Tablespace File The maximum amount (in MB) the data tablespace file
required
Index Tablespace File Size Size of the index tablespace file
Index Tablespace File The maximum amount (in MB) the index tablespace file
required
2. Click Next.
To configure the Core applications, see Configure the Core Applications on page 42.


On the first Case Management, enter the connection parameters for the Case
Management Database on MS SQL Server.
To configure the Case Management Database on MS SQL Server:

1. In the Case Management Database Setup section, select one of the options
Option Description
Create a new database If you select this option, a new database is


core applications.
3. In the Case Management Database Properties section, complete the fields as
Host Host name or IP address of the host server used by the Case Management
Database
Instance Case Management Database instance.
Note: This is an optional field.
Name Name of the Case Management Database
Schema Name of the Case Management Database schema
Note: The dbo (default) schema must be used. You cannot edit the
default entry.

4. Enter the credentials for the Case Management Database in the fields, as described
Administrator Username User name for the Case Management Database

administrator
Administrator Password Password for the Case Management Database

administrator
5. Enter the application user credentials for the Case Management application, as
web applications to connect to the Case Management Database.
Case Management Application Username User name for the Case Management
application
Case Management Application Password Password for the Case Management

application
6. Click Next.
On the second Case Management Database screen, enter the creation parameters for
the Case Management Database on MS SQL Server.
To specify creation parameters for the Case Management Database on MS SQL

Server:
Directory Path to the directory of the Case Management Database files.
Name Name of the data file for the Case Management Database
Size Size (in MB) of the data file for the Case Management Database

Name Name of the log file for the Case Management Database
Size Size (in MB) of the log file for the Case Management Database
Growth The maximum amount (in MB) the log file for the Case Management
Database is allowed to increase in size when additional space is required
3. Click Next.
To configure the Core applications, see Configure the Core Applications on page 42.
Configure the Core Applications

On the Core Applications screens, you provide parameters required to connect the
Core application to the databases and core application server.
By default, the .war files are saved for later use. In this case, fully configured .war
files are created during the installation which should be deployed manually later on.
For more information, see Deploy Web Applications on page 50.
Specify Connection Parameters for WebSphere
Specify Connection Parameters for Tomcat
Specify Connection Parameters for WebLogic
Specify Connection Parameters for JBoss

Enter the connection parameters for the WebSphere application server in the following
screen.
To specify connection parameters for the WebSphere application server:

1. If you want to install the image service, select Install the Image Service.
Note: This option is available only if you selected Adaptive Authentication

Admin on the Installation Components screen.

2. In the Web Services Credentials section, enter the credentials you want to use to
access the core applications.
Username User name for the core applications
Password Password for the core applications
Note: The password must be at least 8 characters and no longer than 16

characters, composed of at least 1 character from each group: letters,
digits, and special characters (-_.!@#$%^*&).
3. In the Application Server Properties section, complete the fields as described in

Host Host name or IP address of the host for the application server of the core
applications
Port Listening port for the application server of the core applications (usually
8080.
4. Click Next.
To specify the configuration parameters for the Core applications, see Specify
Configuration Parameters for the Core Applications on page 45.

Enter the connection parameters for the Tomcat application server in the Core
Applications screen.
By default, the .war file are saved for later use. In this case, fully configured .war files
are created during the installation which should be deployed manually later on. For
more information, see Deploy Web Applications on page 50.
To specify connection parameters for the Tomcat application server:

1. In the Web Services Credentials section, enter the credentials you want to use to
access the core applications.
Username User name for the core applications
Password Password for the core applications
Note: The password must be at least 8 characters and no longer than 16

characters, composed of at least 1 character from each group: letters,
digits, and special characters (-_.!@#$%^*&).


applications
9080.)
3. Click Next.
To specify the configuration parameters for the core applications, see Specify

Enter the connection parameters for the WebLogic application server in the Core
To specify connection parameters for the WebLogic application server:

1. On the Core Applications screen, in the JDBC section, select Modify the default
JDBC URL to suit the environment if you want to modify the default JDBC
URL that displays in the Core JDBC URL field.
2. In the Core Database JNDI Name field, enter the name of the JNDI used by the
AdaptiveAuthentication application to connect to the Core Database. The default
value is PassMarkDB.
Field Description
applications
7001)
4. Click Next.


Enter the connection parameters for the JBoss application server in the Core
To specify connection parameters for the JBoss application server:

AdaptiveAuthentication application to connect to the Core Database. The default
Field Description
applications
8080)
4. Click Next.
Specify Configuration Parameters for the Core Applications

On the second Core Applications screen, provide configuration parameters for the
core applications.
Configure the Back Office Applications

On the Back Office Applications screens, provide parameters required to connect the
Back Office applications to the databases and the application server. This section
contains the following topics:
Specify Back Office Connection Parameters for WebSphere
Specify Back Office Connection Parameters for Tomcat
Specify Back Office Connection Parameters for WebLogic
Specify Back Office Connection Parameters for JBoss


Enter the connection parameters for the WebSphere application server in the Back
Office Applications screen.

By default, the .war file are saved for later use. In this case, fully configured .war files
are created during the installation, which you should manually deploy later. For more
information, see Deploy Web Applications on page 50.
1. In the Application Server Properties section, in the Host field, enter the host
name or IP address of the host for the application server of the Back Office
applications.
2. In the WebSphere Properties section, in the Applications Port field, enter the
HTTP Transport port to which the applications are bound (usually 9080).
3. Click Next.

Enter the connection parameters for the Tomcat application server in the Back Office

Host Host name or IP address of the host for the application server of the Back
Office applications
Port Listening port for the application server of the Back Office applications
(usually 8080)

Enter the connection parameters for the WebLogic application server in the Back
Office Applications screen.

1. If you do not want to deploy the Back Office applications, select the option Save
the .war file(s) for later use. In this case, fully configured .war files are created
during the installation, which you can manually deploy later.
2. If you want to deploy the Back Office applications, select the option Deploy the
Back Office applications.
Note: Only select this option if you chose to install the Back Office Database on
the Installation Components screen or if the Back Office Database is already
installed.

3. In the JDBC URLs section, select the checkbox Modify the default JDBC
URLs to suit the environment if you want to modify the default JDBC URLs
that appear in the fields. The three fields include the URLs for the Core Database,
the Back Office Database, and the Case Management Database.
Office applications
(usually 7001)
5. In the Application Server Credentials section, complete the fields as described

Administrator Username Administrator user name for the application server of the
Back Office applications
Administrator Password Administrator password for the application server of the

Back Office applications
6. In the WebLogic Properties section, complete the fields as described in the

following table.
Bea Home Directory The BEA home directory that functions as a repository
for common files used by multiple BEA products
installed on the same machine. For example, on
Windows, the BEA Home directory is c:\bea.
Home Directory The directory where the WebLogic Server program files
reside. For example, on Windows, the Server Home
directory is c:\bea\wlserver_version. This directory
contains the following folders:
common
samples
server
uninstall
Domain The name of the WebLogic Server domain provided by

the System Administrator while installing WebLogic.
For example, wl_server.

Server The name of the server configured in the current

WebLogic Server domain. For example,
examplesServer.
7. Click Next.
Note: If you chose to deploy the Back Office applications, the installer program
validates the connection details.

Use the Back Office Applications screen to enter the connection parameters for the
JBoss application server.

1. In the JDBC section, select Modify the default JDBC URLs to suit the
environment if you want to modify the default JDBC URLs that are displayed in
the fields. The three fields include the URLs for the Core Database, the Back
Office Database, and the Case Management Database.
2. In the JNDI Name fields, specify the JNDI names used by the Adaptive
Authentication application to connect to the Core Database, Back Office
Database, and Case Management Database, for example, PassMarkDB,
PassmarkToolDB, and CMDB, respectively.
Field Description
Office applications
(usually 8080)
4. Click Next.
The Upgrade Parameters Summary page is displayed.

Review the Installation Parameters

The Installation Parameters Summary screen provides a summary of your entries and
selections in the installation module.
After you review the summary, you can activate the installation from this screen.
To proceed with the installation:

1. Review the installation parameters summary.
2. If the installation parameters do not suit your requirements, do the following:
a. Click Back on each screen until you reach the screen where you want to
change your entry or selection.
b. Change your entry or selection.
c. Click Next to continue to the Installation Parameters Summary screen.
3. If the installation parameters in the summary suit your requirements, click Install
to proceed with the installation.
The installation begins. A series of progress screens indicate the progress of the
installation according to your selections in the installation module.
Review the Installation Summary

When the installation is complete, the Installation Summary screen provides a detailed
summary of the installation.
The summary includes the following information:
A link to the install.log file.
A link for each database to the artifacts directory that contains the SQL scripts
you can deploy at a later time, if you chose to save and not deploy the SQL files
during the installation setup.
A link to the artifacts/webapps directory that contains .war files you need to
deploy at a later time. For more information, see Deploy Web Applications on
page 50.
Click Finish to close the installation module.
Note: There are some components that are not installed by the installation
module. For more information, see Chapter 7, Configure Adaptive Authentication
Applications.

Perform Post Installation Tasks

After the installation module completes, you must perform the following tasks for the
installation to be successful:
Deploy Web Applications
Replacing the Quartz Library in JBoss
Configuring Parameters in the Administration Console
Copy External Data Provider Files
Note: Though you can install Adaptive Authentication on multiple application

servers, you must install the Scheduler web application only on a single server.
Before You Begin

The size of the physical memory in an application server is configured in the startup
script of that application server. The startup scripts for the supported application
servers are as follows:
For WebSphere: startServer.sh
For JBoss: run.sh
For Tomcat: startup.sh
For WebLogic: startWeblogic.sh
1. Set up your application server as described in Appendix A, Set Up the Application
Servers.
2. If your application server is running a UNIX-based operating system, set the size
of the physical memory in your application server to unlimited.
Update the startup scripts by adding the following command according to the
operating system running on your application server.
On AIX, add the command:
ulimit -m unlimited
On Solaris and Linux, add the command:
ulimit -v unlimited

To deploy the web applications on the Tomcat 7.0 application server:

1. Add the following JDBC data source to the server.xml file:
Note: If the core applications and Back Office applications are on different
application servers, add the Back Office and Case Management JDBC data
sources to the server.xml file on the Back Office Database server and the core
JDBC data source to the server.xml file on the Core Database server.
<Resource auth="Container"
driverClassName="com.microsoft.sqlserver.jdbc.SQLServerDr
iver" maxActive="100" maxIdle="30" maxWait="10000"
name="jdbc/PassmarkToolDB" password=valid_secure_password
type="javax.sql.DataSource"
url="jdbc:sqlserver://localhost:1433;databaseName=RSA_BO_
AA" username=username/>
name="jdbc/CMDB" password=valid_secure_password
url="jdbc:sqlserver://localhost:1433;databaseName=RSA_CM_
AA" username=username/>
name="jdbc/PassMarkDB" password=valid_secure_password
url="jdbc:sqlserver://localhost:1433;databaseName=RSA_COR
E_AA" username=username/>
Change the parameters based on your installation environment.
Note: The user name and password should be the application user name and
password you provided during installation.
2. From the META-INF/ directory for each .war file you are going to deploy:
a. Extract the context.xml file to a temporary location and open it in a text
editor.
b. Delete the antiResourceLocking=true flag.
c. Delete the Reloadable=true flag.
d. Save the file.
e. Add the file back to the .war
3. Deploy the .war files.

To deploy the web applications on the WebLogic application server:

1. Create three JDBC datasources: jdbc/PassmarkToolDB, jdbc/CMDB, and
jdbc/PassMarkDB. For more information, see Setting Up the BEA WebLogic
Application Server on page 163.
2. Locate the configured .war files in the artifacts/webapps directory in the
installation directory.
3. Extract the contents of the .war file onto the file system.
4. Deploy the contents of the .war files in the WebLogic Administration Console.
Note: When you install the Scheduler on the WebLogic application server,
you are asked to choose a work manager. Ensure that you select the work
manager, wm/WorkManager.
To deploy the web applications on the JBoss application server:

1. Locate the configured .war files in the artifacts/webapps directory in the upgrade
directory.
2. Extract the contents of the .war files onto the file system in the directory where the
applications are deployed.
3. Deploy the .war files in the JBoss Administration Console.
To deploy the web applications on the WebSphere application server:

jdbc/PassMarkDB. For more information, see Appendix A, Set Up the
Application Servers.
2. Create an additional work manager with a JNDI name, wm/offlineTask:
Configure a minimum threads parameter for the wm/offlineTask work
manager to be 10.
Set the Growable parameter for the work manager to False.
4. Deploy the .war files in the WebSphere Administrative Console.
While deploying the Adaptive Authentication web application and the Scheduler
web application, when prompted to choose a work manager:
For the Adaptive Authentication web application, select the default work
manager, wm/default.
For the Scheduler web application, select both the default work manager,
wm/default, and the Offline Tasks dedicated work manager, wm/offlineTask.
5. Set a context root for each web application. The context root should be the same
as the web application name. For example, the context root for the Adaptive
Authentication web application should be /AdaptiveAuthentication.

6. After you install the web applications on the WebSphere application server, ensure
that the class loader order is set to Classes loaded with local class loader first
(parent last). For more information, see Setting the Class Loader Order on
page 53.
Setting the Class Loader Order
To set the class loader order on supported WebSphere Application Server

versions 7.0, 8.0, and 8.5:
1. Log on to the WebSphere Administration Console.
2. Select Applications Types > WebSphere enterprise applications, and select the
web application that you want to deploy.
Note: You must perform this step for the Adaptive Authentication, Adaptive
Authentication Admin, and all Back Office applications.
3. In Detail Properties, click Class loading and update detection.

4. In the Class loader order area, select Classes loaded with local class loader first
(parent last).
5. Under the web application you selected in step 2, in the Modules section, click
Manage Modules.
6. Click the module for which you want to change the setting.
7. In the Configuration tab, in the Class loader order field, select Classes loaded
with local class loader first (parent last).
8. Click OK.
9. Click Save to save the changes to the master configuration.
Enable Cookies
To enable cookies on the Websphere Application Server:

2. Select Servers > Application servers > <application server name>.
a. Click Session management.
b. Select Enable cookies and click Apply.
c. Click Save to save the changes to the master configuration.
d. Restart the websphere application server.
Replacing the Quartz Library in JBoss

JBoss 5.1 ships with Quartz 1.5.2, which is not compatible with the code used in the
Adaptive Authentication Scheduler application. If you are installing RSA Adaptive
Authentication (On-Premise) 7.1 on a JBoss application server, you must replace the
Quartz library in JBoss with the library provided with the Scheduler distribution
package.

To replace the Quartz library in JBoss:

1. After you complete the dry run of the installation module, navigate to the
scheduler.war/WEB-INF/lib directory, and copy the quartz-all-1.6.1.jar file to
the common/lib directory of JBoss.
2. Delete the common/lib/quartz.jar file in the JBoss installation directory.
Note: For more information on why the obsolete Quartz version could cause
problems, see https://jira.jboss.org/browse/JBAS-6133.
Configuring Parameters in the Administration Console

After performing a clean installation of Adaptive Authentication (On-Premise) 7.1,
you must configure the following parameters in the Administration Console:
Staging Directory Name
Database Directory Name
Archive Directory Name
Active Data File
Mobile Detector Active Data File
WS Caller Name
WS Caller Password
Admin WS Caller Name
Admin WS Caller Password
(Optional) IP Restriction
Report Path and Name
For more information about configuring these parameters, refer to the chapter
Administration Console in the Operations Guide.

The External Data Providers directory contains the files you need to work with the
GeoIP and channel determination features, respectively.
Note: Channel determination did not exist before Adaptive Authentication

(On-Premise) 6.0.2.1 SP3 P1.
Copy the Maxmind geoIP file

The MaxmindGeoIP file is used to determine the country and region from which an IP
address originates.

To copy the Maxmind geoIP file:

1. From the External Data Providers directory in the installation package, copy the
geoip_MAXMIND_version number.dat to
<drive>\RSA\external_data\database directory.
2. In the Administration Console, enter the location of the
geoip_MAXMIND_version number.dat file in the Active Data File field under
the External Data Providers page.
For more information, refer to the sections about updating GeoIP information and
configuring external data providers in the Operations Guide.
Copy the Channel Determination File:

The channel determination file contains information about mobile phones and the
versions of the software running on mobile phones.
To copy the channel determination file

1. From the External Data Providers folder created during the installation, copy the
Channel_Determination.zip to <drive>\RSA\external_data\database
directory.
2. In the Administration Console, enter the location of the
Channel_Determination.zip file in the Mobile Detector Active Data File field
under the External Data Providers page.
For more information, refer to the topics about mobile detection and configuring
external data providers in the Operations Guide.
Complete a Dry-Run Installation

If you chose to do a dry-run of the installation, you must perform the following tasks
to complete the installation:
Run SQL Scripts
Add a Caller in the Web Services Credential Manager
Set Up the Trusted Certificate for WebSphere
Run SQL Scripts

If you did not run the database scripts during the installation (dry-run), you must
manually run the SQL scripts in numerical order according to their file names.
SQL Scripts for Oracle

You must run the SQL scripts for the Core database using the credentials listed in the
following table.
Script Credential
10_DBA_CreateEnv.sql System user

Script Credential
15_DBA_CreateBLOBTablespace.sql System user
20_DropSchemaObjects.sql Application user
30_Create_CORE_7.0.0.0.sql Schema user
32_Create_CRE_3.0.0.0.sql Schema user
Important: If you are working with database partitioning,

you must run 35_Create_CRE_PARTITIONS_3.0.0.0.sql
instead of the above script.
34_Create_PM_2.0.0.sql Schema user
40_CreateCoreData_71.sql Schema user
63_Long_Auth_db_changes.sql Schema user
65a_21_to_251_AddModelColumnToEventLog.sql Schema user
65b_251_to_30_AddModelColumnToEventLog.sql Schema user
80_CreateCREData.sql Schema user
90_CreateCREData_scratch.sql Application user
92_CreateCREData_nongenerated.sql Application user
94_CreateCREData_general.sql Application user
97_CreateCREData_maxmind.sql Application user
981_Grant_Privileges.sql schema user
982_APP_synonyms_changes.sql Application user
99_APP_UpdateDbVersion.sql Application user
You must run the SQL scripts for the Back Office database using the credentials listed
Script Credential
30_Create_BO_7.0.0.0.sql Schema user
40_CreateBOData_70.sql Schema user

Script Credential
You must run the SQL scripts for the Case Management database using the credentials
listed in the following table.
Script Credential
30_Create_CM_7.0.0.0.sql Schema user
40_CreateCMData_70.sql Schema user
62_CM_Enhancements.sql Schema user
SQL Scripts for SQL Server

You must run the SQL scripts for the Core database using the credentials listed in the
following table.
Script Credential
30_Create_CORE_7.1.0.0.sql DBA user
32_Create_CRE_3.0.0.0.sql DBA user
34_Create_PM_2.0.0.sql DBA user
40_CreateCoreData_71.sql DBA user
61_AA71_db_changes.sql DBA user
65a_21_to_251_AddModelColumnToEvent DBA user

Log.sql

Script Credential
65b_251_to_30_AddModelColumnToEvent DBA user

Log.sql
80_CreateCREData.sql DBA user
90_CreateCREData_scratch.sql Application user
94_CreateCREData_general.sql Application user
97_CreateCREData_maxmind.sql Application user
981_Grant_Privileges.sql DBA user
You must run the SQL scripts for the Back Office database using the credentials listed
Script Credential
30_Create_BO_7.1.0.0.sql DBA user
40_CreateBOData_71.sql DBA user
You must run the SQL scripts for the Case Management database using the credentials
listed in the following table.
Script Credential
30_Create_CM_7.1.0.0.sql DBA user
40_CreateCMData_71.sql DBA user
62_CM_Enhancements.sql Schema user


jdbc/PassMarkDB. For more information, see Setting Up the BEA WebLogic
Application Server on page 163.
3. Unzip the .war files to a location of your choice.
4. Deploy the .war files in the WebLogic Administration Console.
Note: When you install the Scheduler on the WebLogic application server, you are
prompted to choose a work manager. Ensure that you select the work manager,
wm/WorkManager.

1. Locate the configured .war files in the artifacts/webapps directory in the upgrade
directory.
Note: When you install the Scheduler on the JBoss application server, you must
define a new thread pool with default settings dedicated to offline tasks
(OfflineTaskThreadPool). For more information, see Configure a Separate Work
Manager for RSA Risk Engine Offline Tasks on page 125.
If you manually deploy the web applications on the JBoss application server, you must
ensure that the web application directory ends with the suffix .war, for example,
server/default/deploy/AdaptiveAuthentication.war.
When you deploy the Adaptive Authentication application on the JBoss application
server, you must specify an absolute path for the CSS File and Logo File fields in the
Administration Console.
You can configure these fields by logging on to the Administration Console and
editing the following fields.
Authentication Methods > Out-Of-Band E-mail > CSS File
Authentication Methods > Out of Band E-mail > Logo File
The CSS file is available in the
JBOSS_HOME/server/default/deploy/AdaptiveAuthentication.war/css folder.
The logo file is available in the
JBOSS_HOME/server/default/deploy/AdaptiveAuthentication.war/images folder.

Add a Caller in the Web Services Credential Manager

To add a caller:
1. Go to http://hostname:port number/wscredentialmanager.
2. Enter the user ID and password, and click Login. The default values of user ID
and password are admin/admin.
3. Add a new caller, as follows:
a. Enter values for the following fields.
Name
Password
Confirm Password
Organization
b. Click Save.
Set Up the Trusted Certificate for WebSphere

To allow the RSA eFraudNetwork agent to make an HTTPs request to the
eFraudNetwork service at RSA, you need to download and install the Trusted
Certificate for WebSphere.
For information about setting up the trusted certificate for WebSphere, see Set Up a
Trusted Certificate on page 157.
Test the Installation

After you complete the installation using the installation module, you can confirm that
the Adaptive Authentication (On-Premise) application system is installed correctly by
checking the installation of the core applications and Back Office applications.
Check the Installation of Core Applications

To check the installation of the core applications that you selected during the
installation, you can run the health checks using the HealthCheckServlet. The
HealthCheckServlet requires you to provide the Web Services credentials (core
applications access credentials).
To run the health checks:

1. Go to http://host:port/AdaptiveAuthentication.
2. Enter the caller ID and password and click Login.
3. Click the Health Check Servlet link.
The HealthCheck Results screen appears with the results of each test. The results
appear in a table that provides information about which modules are checked and
the results of each check.

Note: The first time you run the Health Check Servlet immediately after the
installation, the Risk Engine Health Check task scheduled to run at midnight every
day never runs. In this case, there is a warning that there is no information on these
tasks.
Checking the Installation of Back Office Applications

To check the installation of the Back Office applications that you have selected for the
installation, open and log on to each Back Office application, in any order, to make
sure they are functioning. You must log on to the Back Office applications using
admin/admin as the user name and password.
The following table lists the URLs that you can use to log on to the different Back
Office applications and the actions you can perform to check if the applications
function correctly.
Back Office
URL Check Functionality
Application
Access Management http://hostname:port number/accessmanagement Add new Back Office

applications users,
organizations, and groups
Assign roles to Back Office
users
Back Office http://hostname:port number/backoffice Define system parameters

Search for end users
Note: This URL should be used to access the Lock /unlock end users
following applications:
Unenroll end users
Administration Console
Add new rules and conditions
Customer Service for several event type
Policy Management Add IP, user, and country
from List Administration
Case Management http://hostname:port number/casemanagement Search for end users

View case details
Create operators and operator
groups
Report Viewer http://hostname:port number/reportviewer Search for reports based on

search criteria
Web Services http://hostname:port number/wscredentialmanager Add a new caller

Credential Manager Edit caller details

Back Office
URL Check Functionality
Application
Scheduler http://hostname:port number/scheduler Risk Engine Offline Tasks

Risk Engine Health Checks
Case Logger
Events Marking Logger
Delete Bindings
Delete Unused Desktops
Delete Users
Delete Org
EFN Agent
For the Back Office applications, a load balancer is defined to distribute the workload
evenly across two or more servers to avoid overload. You can use sticky sessions,
configured by the load balancer, to improve efficiency of persistent sessions.
Sticky sessions are those sessions, residing on a single server, that received the web
request and require you to log on to the server only for the first request. All subsequent
requests are routed to the same server.
Note: After installing on WebSphere, if you get a ResultSet closed' exception in the
aa_server.log file, you must set the resultSetHoldability custom property to 1 instead
of 2.
Uninstall Adaptive Authentication (On-Premise)

To uninstall Adaptive Authentication (On-Premise):
Delete the Databases
Uninstall the Web Applications
Delete Generated Files
Delete the Databases

Delete the Core, Back Office, and Case Management databases on Oracle and MS
SQL Server.
To delete the databases on Oracle:

Log on to the database as the system user and enter the following SQL statement:
drop user username cascade

To delete the databases on MS SQL Server:

1. Open the MS SQL Server Manager using database administrator (DBA)
credentials.
2. Delete the databases.
Note: On Unix, log on as the instance user and use the drop command to delete the
databases.
Uninstall the Web Applications

To uninstall the web applications on Tomcat:
1. Stop the application server.
2. Delete the applications from the webapps directory.
3. Delete the context files from the conf directory.
4. Remove the JDBC resources from the file server.xml.
5. Delete the work directory.
Note: This is the Tomcat cache.
6. Restart the application server.
To uninstall the web applications on WebSphere:

1. Log on to the WebSphere Administrative Console.
2. Delete the web applications.
3. Delete the JDBC data sources.
Delete Generated Files

To uninstall the files generated by the installation module:
1. Delete the main directory that you selected during installation.
2. Delete the directory where the installation files are located.

4 Prepare to Upgrade
Upgrade Prerequisites
This chapter lists the prerequisites to consider and the tasks you must perform before
upgrading to RSA Adaptive Authentication (On-Premise) 7.1.
Upgrade Prerequisites
Note: For more information about hardware and operating system requirements, see
the RSA Adaptive Authentication (On-Premise) 7.1 Release Notes.
Ensure that you meet the following requirements before upgrading to RSA Adaptive
Back up the databases.
Note: This is important if you want to roll back to the existing version of Adaptive
Back up the configuration files from the previous installation.

Back up the log4j files from the previous installation so that you can manually
restore them after the upgrade.
Rename the .varfile to be the same as the upgrade module. When you run the
upgrade module with the .varfile in the same folder, it populates the fields in the
wizard with values from the .varfile.
Back up the c-authentify-requestResource.auth file.
For users upgrading from RSA Adaptive Authentication (On-Premise) 6.0.2.1
SP2:
a. Create a directory named v7.1_upgrade under the main_directory.
main_directory is the directory that was selected when you installed
RSA Adaptive Authentication (On-Premise) 6.0.2.1 SP2. For example, c:\rsa
on Windows. This directory contains the configs directory.
Note: On UNIX, if you fail to either create the v7.1_upgrade folder or copy
the required files to this folder, in some cases, the upgrade process gets stuck
and enters an endless loop. To solve this issue, you must stop the upgrade
process by force, meet all of the missing prerequisites, and run the upgrade
module again.
4: Prepare to Upgrade 65
b. Copy the following files from Adaptive Authentication (On-Premise) 6.0.2.1

SP2 to the v7.1_upgrade directory:
config.properties, located in the
AdaptiveAuthentication\WEB-INF\classes\ directory.
Note: The config.properties file is a mandatory file. The upgrade will not
proceed without this file. Depending on your specific setup, some of the other
files may not be available.
aa-backoffice-config.xml, located in the

accessmanagement\WEB-INF\config\ directory.
database.properties, located in the scheduler\WEB-INF\classes\
directory.
casemanagement-config.xml, located in the
casemanagement\WEB-INF\config\ directory.
Note: The upgrade module tries to locate the casemanagement-config.xml

file in the main_dir/bo_configs/casemanagement folder. If the file does not
exist in this location, the upgrade module prompts you to copy it from the
Case Management application.
Check that the Scheduler Offline task process completed successfully for each of
the last seven days. If the Offline task process did not complete successfully, run
the Offline task process again to recover the data that was not migrated.
During the upgrade summary phase, verify that no warnings were issued during
the Core database upgrade. For more information, see Troubleshooting After the
Upgrade on page 95.
If you run the upgrade module on Solaris with JRE 1.6 or if you have used
encryption in RSA Adaptive Authentication (On-Premise) 6.0.2.1 SP2, after
upgrading to RSA Adaptive Authentication (On-Premise) 7.1, you might face
backward compatibility issues. To successfully decrypt the data in RSA Adaptive
Authentication (On-Premise) 7.1, you must make the following changes in the
JDK:
a. Locate the java.security file in the path_to_JRE/lib/security directory and
open it for editing.
b. Locate the following line:
securerandom.source=file:/dev/urandom
and change it, as follows:
securerandom.source=file:/dev/random
66 4: Prepare to Upgrade
c. Locate the section that looks similar to the following:

der
SigRI
d. Move the SunPKCS11 security provider to the end of the list and renumber,
as follows:
der
SigRI
Prerequisites for MS SQL
For WebSphere Application server only:

Ensure the following issues before upgrade:
To ensure the database supports the non-Unicode character set, for example,
Chinese, open the WebSphere Administrative Console. Under Resources -> Data
sources -> custom properties -> sendStringParametersAsunicode, change the
value to True and restart the server.
The WebSphere application server enforces the highest isolation level supported
by the database. For MS SQL databases, the highest isolation level supported is
TRANSACTION_REPEATABLE_READ (4), which can cause escalation locks.
To avoid this, you must lower the isolation level by resetting the
webSphereDefaultIsolationLevel property of the datasource to
TRANSACTION_READ_COMMITTED (2).
For instructions on adding the custom property for a data source using the
WebSphere Administrative Console, go to
http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg21224492.
Prerequisites for Oracle
For Unix (only):

If you need to upgrade Oracle on Unix and you are not the Oracle instance user, do the
following:
1. Log on to the Unix machine as the Oracle software owner.
2. Verify that the ORACLE_HOME variable is set.
Setting a system variable in Unix differs depending on the Unix shell in which
you are working.
For example:
For sh or bash export ORACLE_HOME=oracle_home_dir
For csh or tcsh setenv ORACLE_HOME oracle_home_dir
For other Unix shells, consult your Unix documentation.
3. Make sure you have the required privileges on the instance directory. From the
root user, run the following command:
chmod -R 755 $ORACLE_HOME/*
4. Run the setting command before you begin the upgrade process:
export ORACLE_HOME=Oracle_Home_full_path
export ORACLE_SID=Oracle_SID
For Windows and Unix:

Grant the Core schema owner privileges to create views before you run the
upgrade module. To grant the privilege, type:
grant create view to core_schema_owner
Note: You must connect to Oracle as the system user to grant this privilege to the
Core schema owner.
Grant the Case Management schema owner the privilege to create views before
you run the upgrade module. To grant the privilege, type:
grant create view to case_management_schema_owner
where case_management_schema_owner is the schema owner for the Case
Management database. This is different from the application user.
Note: You must connect to Oracle as the system user to grant this privilege to the
Case Management schema owner.
You must grant permissions to access the following package to update the risk
engine data:
grant execute on dbms_alert to <core.db.schema> ;
The permissions must be granted by the SYS user.
Set the oracle JOB_QUEUE_PROCESSES parameter to 10 before migrating the
Risk Engine.
Prerequisites for BSafe

You must apply a patch to avoid getting a security exception on the Sun or IBM JDK.
The java.security.InvalidKeyException:illegal Key Size error is a common issue
that occurs when you try to invoke a secured web service in an environment where the
provision for java unlimited security jurisdiction is unavailable. You may also see
errors related to java.security.NoSuchAlgorithmException.
You can avoid these exceptions by applying the patch that installs Java Cryptography
Extension (JCE) unlimited strength jurisdiction policy files.
To apply the patch:

1. Download the Java Cryptography Extension (JCE) Unlimited Strength
Jurisdiction Policy Files for your JDK version, as shown in the following table.
JDK Version Procedure
JDK 1.6 Download jce_policy-6.zip. The package is available from the

official java web site.
IBM JDK 1. Go to
https://www14.software.ibm.com/webapp/iwm/web/preLo
gin.do?source=jcesdk.
2. Select Unrestricted JCE Policy files for SDK for all newer
versions (Version 1.4.2 +), click Continue, and then click
Download now to download the zip file.
BEA JDK 1. Go to
https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CD
S-CDS_Developer-Site/en_US/-/USD/ViewProductDetail-S
tart?ProductRef=jce_policy-1.5.0-oth-JPR@CDS-CDS_De
veloper.
2. Download jce_policy-1_5_0.zip.
3. Extract the local_policy.jar and US_export_policy.jar files in the zip file to the
$JAVA_HOME/jre/lib/security directory.
These files already exist in this directory. You must overwrite them.
4. Restart the application server, and reinvoke the secured service.
Check that the invalidkeyException does not occur.
Prerequisites for WebLogic

If you use WebLogic 10.3.3, you might observe runtime exceptions because
WebLogic 10.3.3 is not compliant with JPA 2.0. To avoid this, do one of the
following:
Upgrade from WebLogic 10.3.3 to WebLogic 10.3.4, and then install the official
patch QWG8 on top of WebLogic 10.3.4
If you cannot upgrade to WebLogic 10.3.4, contact Oracle or WebLogic Customer
Support to obtain the following jar files:
com.oracle.jpa2support_1.0.0.0_2-0.jar
javax.persistence_1.0.0.0_2-0-0.jar
Ensure that you place these two jar files at the beginning of the WebLogic
classpath so that these files get loaded before the other files when the WebLogic
process starts.
Edit the startWebLogic.cmd startup script file using a text editor, as follows:
a. Locate the "set CLASSPATH" statement.
b. Verify that the javax.persistence_1.0.0.0_2-0-0.jar is listed first in the

classpath. For example, if Weblogic is installed in the c:\Oracle\Middleware
directory, the entry should appear as follows:
set
CLASSPATH=c:\Oracle\Middleware\modules\javax.persistence_1.0
.0.0_2-0-0.jar;%SAVE_CLASSPATH%
Prerequisites for JBoss

Before upgrading to RSA Adaptive Authentication (On-Premise) 7.1 on the JBoss
application server, you must do the following:
Copy the ehcache-core-2.3.0.jar file from the lib directory of any of the Adaptive
Authentication or Back Office applications to the
JBOSS_HOME/server/default/lib directory.
Copy the JDBC drivers to the JBOSS_HOME\server\default\lib directory.
Configure the JVM memory settings in the JBOSS_HOME\bin\run.conf.bat file
to suit your deployment. The following is the minimum setting for JDK on
Windows:
set "JAVA_OPTS=-Xms1024m -Xmx1024m -XX:PermSize=256m
-XX:MaxPermSize=512m"
Create a file named aaop-ds.xml in the JBOSS_HOME\server\default\deploy
directory and copy the following code snippet into the aaop-ds.xml file:
<?xml version="1.0" encoding="UTF-8"?>
<datasources>
<jndi-name>jdbc/PassMarkDB</jndi-name>
<user-name>core_db_user_name</user-name>
<password>core_db_password</password>
<jndi-name>jdbc/PassmarkToolDB</jndi-name>
<user-name>backoffice_db_user_name</user-name>
<password>backoffice_db_password</password>
<jndi-name>jdbc/CMDB</jndi-name>
<user-name>cm_db_user_name</user-name>
<password>cm_db_password</password>
</datasources>
Disable the CachedConnectionManager for the web server.
Disable JSP pooling.
To disable the CachedConnectionManager for the web server:

1. Navigate to JBOSS_HOME\server\default\deploy\jbossweb.sar.
2. Open the server.xml file, and comment the following element:
<Valve
className="org.jboss.web.tomcat.service.jca.CachedConnect
ionValve"
cachedConnectionManagerObjectName="jboss.jca:service=Cach
edConnectionManager"
transactionManagerObjectName="jboss:service=TransactionMa
nager" />
To disable JSP pooling:

1. Navigate to JBOSS_HOME\server\default\deployers\jbossweb.deployer:
2. Open the web.xml file, add an enablePooling init parameter, and set it to false,
as shown in the following snippet.
<init-param>
<param-name>enablePooling</param-name>
<param-value>false</param-value>
</init-param>
Note: This change is mandatory for the JBoss server that hosts the Back Office
applications.
Adding a Separate Thread Pool for the Risk Engine

On JBoss, you must add a separate thread pool in the
JBOSS_HOME\server\default\deploy\jca-jboss-beans.xml file for offline tasks.
For more information, see Configure a Separate Work Manager for RSA Risk Engine
Offline Tasks on page 125.
5 Upgrade from a Previous Version of

Adaptive Authentication (On-Premise)
Overview of the Upgrade Module
Extract the Upgrade Module
Run the Upgrade Setup Process for Windows
Run the Upgrade Setup Process for Unix
Define the Upgrade
Review the Upgrade Parameters and Activate the Upgrade
Review the Upgrade Summary
Troubleshooting After the Upgrade
Perform Post-Upgrade Tasks
This chapter describes how to upgrade from previous versions of RSA Adaptive
Authentication (On-Premise) to RSA Adaptive Authentication (On-Premise) 7.1 using
the upgrade module.
Note: Before you upgrade, notify RSA Technical Support that you plan to upgrade.
This enables RSA to prepare the necessary RSAC infrastructure.
Overview of the Upgrade Module

The RSA Adaptive Authentication (On-Premise) 7.1 upgrade module is a wizard that
configures the different Adaptive Authentication components based on user input.
During the upgrade process, you must select the components that you want to upgrade
and provide input for their configurations.
The upgrade module configures the database upgrade scripts based on the input you
provide. You can select whether to run the database upgrade scripts automatically
using the upgrade module or to run them manually after the upgrade module
completes.
5: Upgrade from a Previous Version of Adaptive Authentication (On-Premise) 73

Important: The Adaptive Authentication (On-Premise) 7.1 upgrade module does not
support automatic deployment of web applications. You must deploy web applications
manually.
Note: The upgrade module creates a log file of the upgrade run environment and all
the upgrade actions. While the upgrade module is running, a log file named
i4j_log_aaop_<i4j generated number>.log is created in a folder under the user temp
directory. A file named install.log is copied to the directory where the executable is
available after the upgrade module finishes running.
If the upgrade module displays an error message, copy the log file from the temp
directory to the directory of the executable, so that it is available for investigating the
problem.
Installation Varfile
At the end of the upgrade process, the upgrade module saves all of the inputs required
during the process in the upgrade variable file. The name of the variable file is the
same as that of the upgrade executable file, but with the extension .varfile. This
.varfile is created in the same folder as the upgrade module. It is also copied as backup
to the main folder used by Adaptive Authentication.
Important: Save the .varfile for later use. The .varfile can be useful if you want to
rerun the upgrade module or if you want to apply hot fixes or upgrades.
When the upgrade module is executed with the .varfile in the same folder, it populates
the fields in the wizard with values from the .varfile.
Note: Passwords are saved encrypted to the .varfile. If this poses a security risk, you
must manually remove the encrypted password values from the .varfile in both
locations.
Extract the Upgrade Module

The RSA Adaptive Authentication (On-Premise) 7.1 CD contains the artifacts that
you need to upgrade and configure components in the Adaptive Authentication
system.
To extract the upgrade module:

1. Choose the .zip file appropriate for your organization platform from the following
list:
AA-OnPrem.7.1.0.0.0.Unix.Upgrade.zip - for a Unix platform
AA-OnPrem.7.1.0.0.0.64_bit.Upgrade.zip - for Windows 64-bit platform
2. Copy the .zip file from the CD to the machine on which you plan to install
74 5: Upgrade from a Previous Version of Adaptive Authentication (On-Premise)

3. Unzip the .zip file. The .zip file contains the release folder which includes the
following files to upgrade to RSA Adaptive Authentication (On-Premise) 7.1.
Documentation. Contains the Adaptive Authentication (On-Premise) product
documentation.
AA-OnPrem.7.1.0.0.0.Unix.Upgrade.sh - to upgrade on a Unix platform
AA-OnPrem.7.1.0.0.0.64_bit.Upgrade.exe - to upgrade on a Windows
64-bit platform
After you extract the upgrade module from the CD, you are ready to run the upgrade
setup process. For information on running the setup process on Windows, see Run the
Upgrade Setup Process for Windows on page 75. For information on running the setup
process on Unix, see Run the Upgrade Setup Process for Unix on page 76.
Run the Upgrade Setup Process for Windows

This section describes the setup process required prior to running the upgrade to
RSA Adaptive Authentication (On-Premise) 7.1 for Windows platforms.
Before You Begin

Run the upgrade module as a user with sufficient privileges to access all the
affected directories on the file system.
Run the setup process before performing the actual upgrade.
Note: If you are upgrading from RSA Adaptive Authentication (On-Premise) 6.0.2.1
SP2, the upgrade process replaces the following validation files:
validate.emailInfo.properties
validate.phoneInfo.properties
If you have customized these files, you must manually re-apply the changes on the
replaced files. The original files are backed up to the
<RSA_Home>/configs_orig_71_upgrade_bak directory.
Run the upgrade setup process for Windows by doing one of the following procedures.
To run the upgrade setup process for the upgrade module on Windows:
1. Navigate to the Upgrade directory where the upgrade module is located.
2. Double-click the AA-OnPrem.7.1.0.0.0.64_bit.Upgrade.exe file.
The upgrade setup begins. A progress bar indicates the progress of the setup.
To run the upgrade setup process at the command prompt on Windows:


2. At the command prompt, enter the following command:

start /w AA-OnPrem.7.1.0.0.0.64_bit.Upgrade.exe arguments
- c: Runs the upgrade module in command prompt mode.
- q: Runs the upgrade module in unattended mode. This argument must be
used with - varfile.
- varfile installer-responses-file: Reads the responses from a file.
The upgrade setup begins. A progress bar indicates the progress of the setup.
Note: When you run the upgrade module at the command prompt, if you do not
want the password to be displayed in the console during the upgrade, you must
install Java 6.0.
Run the Upgrade Setup Process for Unix

This section describes the setup process required prior to running the upgrade to
RSA Adaptive Authentication (On-Premise) 7.1 for Unix platforms.
Before You Begin

Run the upgrade module as a user with sufficient privileges to access all the
affected directories on the file system.
Run the setup process before performing the actual upgrade.
Note: If you are upgrading from RSA Adaptive Authentication (On-Premise) 6.0.2.1
SP2, the upgrade process replaces the following validation files:
validate.emailInfo.properties
validate.phoneInfo.properties
If you have customized these files, you must manually re-apply the changes on the
replaced files. The original files are backed up to the
<RSA_Home>/configs_orig_71_upgrade_bak directory.
To run the upgrade setup process for the upgrade module on Unix:
2. Ensure that the upgrade script has execute permission. To set the permission, type:
chmod u+x AA-OnPrem.7.1.0.0.0.Unix.Upgrade.sh

3. Type:
./AA-OnPrem.7.1.0.0.0.Unix.Upgrade.sh arguments
c: Runs the upgrade module in command prompt mode.
q: Runs the upgrade module in unattended mode. This argument must be
used with varfile.
varfile installer-responses-file: Reads the responses from a file.
The upgrade setup begins.
Note: If you use FTP, sFTP, or SCP to send the upgrade module files across a
network, use binary transfer mode for the files.
To run the upgrade setup process on UNIX with the Oracle database:
1. Log on using the Oracle user credentials.
2. Run the upgrade module, but select only the databases for upgrade.
3. When the upgrade module completes, check whether the database scripts run
correctly.
4. Log on to the system as the root user, and run the upgrade module again to
complete the upgrade for the other components.
Note: You can choose to run the entire upgrade setup as the root user. For
instructions, see Chapter 4, Prepare to Upgrade.
On a UNIX platform, when running the upgrade module using the -c option, the
following error message may appear:
testing JVM in /usr ...
Starting Upgrade Module...
Could not display the GUI. This application needs access to
an X Server.
*****************
If you have access there is probably an X library missing.You
can also run this application in console mode without access
to an X server by passing the argument -c
*****************
An error occurred:
java.awt.AWTError: Assistive Technology not found:
org.GNOME.Accessibility.JavaBridge
Error log: /var/tmp/install4jError20776.log
*****************
To resolve this issue:

1. Log on as the root user.
2. Edit the /usr/java/jre/lib/accessibility.properties file where /usr/java/jre is the
directory in which the JRE is installed on your machine.
3. Comment out the property assistive_technologies.

4. Save the file and log off.

5. Rerun the upgrade module stating explicitly not to use graphics, as shown:
./AA-OnPrem.7.1.0.0.0.Unix.Upgrade.sh -c
-Dinstall4j.nolaf=true
This command runs the upgrade module without graphics. You can still use a
response file with this command.

This section describes the process for defining the preliminary information needed to
run the upgrade from the upgrade module.
Before You Begin

Install the Scheduler web application only on a single separate server.
Install Adaptive Authentication either across multiple servers or on a single
server, according to your organization preference.
All fields are mandatory unless stated otherwise.
To define the scope of the upgrade process:

1. Read the information on the Welcome screen.
2. Click Next.
3. If you agree with the terms of the License Agreement, select I accept the
agreement.
Note: If you select I dont accept the agreement, you cannot continue with the
upgrade.
4. Click Next.
The Environment Preparation Reminder screen provides a reminder of the
prerequisites to be met before proceeding with the upgrade.
5. Ensure that you have met the requirements specified in Upgrade Prerequisites on
page 65, and click Next.
6. On the Customer Information screen, in the Customer Name field, provide a
customer name for billing purposes, and click Next.
7. On the Upgrade Types screen, select the upgrade type that best suits your
requirements.
Full Recommended. Installs all components including the

databases, core applications, Back Office applications,
development utilities, and maintenance utilities.

Databases Installs only the databases (Core Database, Back Office

Database, and Case Management Database).
Core Applications Installs only the core applications (Adaptive

Authentication, Adaptive Authentication Admin, and the
Scheduler). The databases must already be installed.
Back Office Applications Installs only the Back Office applications. The databases
and core applications must already be installed.
Development Utilities For developers. Installs only the development utilities.

Configure Development Utilities.
Maintenance Utilities For system administrators. Installs only the maintenance

utilities.

Configure Maintenance Utilities.
Custom Installation Installs only selected components.
Important: When running the upgrade process in command line mode, choose
Custom Installation for the upgrade type. Select the specific components
(applications) required for the upgrade.
Define the Upgrade

This section describes how to configure the upgrade parameters using the upgrade
module.
To define the upgrade parameters:

1. Change the default selections.
Depending on the components you choose to install on the Upgrade
Components screen, the options available on the subsequent screens may
vary.
If you select either Development Utilities or Maintenance Utilities on the
Upgrade Components screen, the upgrade module creates a folder called
dev_utils_7.1 or utils_7.1, respectively in the main configuration folder. This
folder contains the new and fixed maintenance or development utilities.
After the upgrade, you must merge any changes done in the original folder to
the new folder and use the new utilities.

If you select Configuration Migration, the Configuration Migration tool

runs. You must set the JAVA_HOME environment variable for the
Configuration Migration tool to run.
2. Click Next.
The Environment screen is displayed.
3. Define the environment for the upgrade.
a. In the Base Version section, select the version of Adaptive Authentication
(On-Premise) that you currently have installed.
b. In the Database Type section, select the database.
c. In the JDBC Driver File field, enter the path to the JDBC driver file. For
example, sqljdbc.jar if you are using MS SQL Server.
d. Verify that the information in the JDBC Driver field is correct.
e. In the Application Server section, select the application server.
Important: You can run RSA Adaptive Authentication web applications on

application servers configured with HTTPS or SSL. To configure the
application server to use HTTPS or SSL, refer to your application server
documentation.
Note: When running the upgrade using the command line, JBOSS and
WebLogic appear as options for the application server, but cannot be selected
as they are not supported in this release.
f. In the Main Directory field, specify the main directory where the
configuration, reports, and log files will be stored.
4. Click Next.
5. On the Configuration Migration screen, you can export the current configuration
and also choose to upload the exported configuration files to the Core Database.
Note: This screen appears only if you are upgrading from RSA Adaptive
Authentication (On-Premise) 6.0.2.1 SP2 and have selected Configuration
Migration on the Upgrade Components screen.
The following procedure describes the configuration migration process when

upgrading from RSA Adaptive Authentication (On-Premise) 6.0.2.1 SP2 to
Before You Begin

The Configuration Migration tool requires a connection to the Core Database to
retrieve ORG information.
The Configuration Migration tool requires the following files to be located in the
main_directory/v7.1_upgrade folder:
AdaptiveAuthentication\WEB-INF\classes\config.properties

accessmanagement\WEB-INF\config\aa-backoffice-config.xml
scheduler\WEB-INF\classes\database.properties
casemanagement\WEB-INF\config\casemanagement-config.xml
The upgrade module tries to locate the casemanagement-config.xml file in the
main_directory/bo_configs/casemanagement folder. If the
casemanagement-config.xml file does not exist in this location, the upgrade
module prompts you to copy it from the Case Management application.
To migrate configuration changes:

1. The upgrade module backs up the old configuration information in the configs
folder as configs_orig_bak.
The configs_orig_bak folder is created by the upgrade module. If the
configs_orig_bak folder exists, as in the case of reruns, the upgrade module
restores the original configurations from this folder to the configs folder, and uses
it to perform the upgrade.
2. Apply the required patches and hot fix XSL files.
3. Run the Configuration Migration tool. You can either choose to automatically run
the tool by selecting Configuration Migration on the Upgrade Components
screen or manually run the tool.
For instructions on running the Configuration Migration tool manually, see
Configuration Migration Tool on page 150.
4. Delete unnecessary files from the configs directory.
5. Apply cleanup XSL files.
6. After the configuration migration from RSA Adaptive Authentication
(On-Premise) 6.0.2.1 SP2 is completed successfully, remove the v7.1_upgrade
folder from the main_directory.
Note: If the Configuration Migration tool fails, look for the following error in the
logs: Cannot find class
[com.rsa.infra.devicetype.detector.impl.wurfl.DeviceTypeResolutionStrategyImpl]
for bean with name 'deviceTypeResolutionStrategy' defined in ConfigResource.
If you find this error, in the /AdaptiveAuthentication/WEB-INF/classes/configs/
directory, delete the c-config-deviceTypeDetector.xml file. Run the Configuration
Migration tool again. After the Configuration Migration tool has run, configure the
Mobile Detector Active Data File parameter in the Administration Console.


Using the Core Database screens, you provide parameters required by the Core
Database.
Important: If you are using the Tomcat application server, and are concerned about
your database passwords being stored in clear text in the Tomcat server.xml file, see
Secure the Data Source Password for Tomcat on page 126.
If you choose to install the databases, the relevant logs are created as *.log files in the
directory where the executable is available. You must attach the log files when you
contact RSA Customer Support about an upgrade problem.

Use the Core Database screen to enter the connection parameters for the Core
Database on Oracle.
To configure the Core Database on Oracle:

1. (Optional). On the Core Database screen, select Run the SQL scripts if you want
the upgrade module to run the sql scripts during the upgrade.
parameters, but are not run automatically. You must manually run the SQL scripts.
For more information, see Run SQL Scripts on page 103.
following table.
Field Description

Core Database
Name (SID) Database system ID (SID) of the host where the Core
Database resides
Alias Name (TNS) TNS name of the Core Database
BLOB Tablespace Name Name of the BLOB tablespace

3. In the Core Database Credentials section, enter the values as described in the
following table.
Field Description
4. Click Next.
To upgrade the Back Office database, go to Configure the Back Office Database on
Oracle on page 85.

Use the Core Database screen to enter the connection parameters for the Core
To configure the Core Database on MS SQL Server:

1. (Optional). On the Core Database screen, select Run the sql scripts if you want
the upgrade module to run the SQL scripts during the upgrade.
following table.
Field Description
Host Host name or IP address of the host server used by the Core Database
Note: Do not enter a value for the port if you are connecting to a database
instance.
Instance The Core Database instance. Enter the complete database instance name
you used when you created the database.
This is an optional field. You must enter a value in this field only if you
are not using the default instance.
Name Name of the Core Database

Field Description
Schema Name of the Core Database schema
entry.
3. Enter the credentials for the Core Database as described in the following table.
Field Description
Administrator Username User name for the Core Database administrator
Administrator Password Password for the Core Database administrator
4. Enter the application user credentials for the Core applications, as described in the
following table. The application user credentials are used by the web applications
to connect to the Core Database.
Field Description
5. Click Next.
To upgrade the Back Office database, go to Configure the Back Office Database on
MS SQL Server on page 86.

Use the Back Office Database screens to provide parameters required by the Back
Office Database.
Important: If you are using the Tomcat application server, and are concerned about
your database passwords being stored in clear text in the Tomcat server.xml file, see
Secure the Data Source Password for Tomcat on page 126.



Use the Back Office Database screen to enter the connection parameters for the Back
Office Database on Oracle.
To configure the Back Office Database on Oracle:

1. (Optional). On the Back Office Database screen, select Run the sql scripts if you
want the upgrade module to run the SQL scripts during the upgrade.
2. In the Back Office Database Properties section, enter the values as described in
Field Description

Back Office Database
Name (SID) Database system ID (SID) of the host where the Back
Office Database resides
Alias Name (TNS) TNS name of the Back Office Database
3. In the Back Office Database Credentials section, enter the values as described in
Field Description
4. Click Next.
To upgrade the Case Management database, go to Configure the Case Management
Database on Oracle on page 87.


Use the Back Office Database screen to enter the connection parameters for the Back
Office Database on MS SQL Server.
To configure the Back Office Database on MS SQL Server:

1. (Optional). On the Back Office Database screen, select Run the sql scripts if you
want the upgrade module to run the SQL scripts during the upgrade.
2. In the Back Office Database Properties section, complete the fields as described
Field Description
Host Host name or IP address of the host server used by the Back Office
Database
instance.
Instance Back Office Database instance

This is an optional field. You must enter a value in this field only if you
are not using the default instance.
Name Name of the Back Office Database
Schema Name of the Back Office Database schema
entry.
3. Enter the credentials for the Back Office Database, as described in the following
table.
Field Description
Administrator Username User name for the Back Office Database administrator
Administrator Password Password for the Back Office Database administrator

4. Enter the application user credentials for the Back Office applications, as
web applications to connect to the Back Office Database.
Field Description
5. Click Next.
To upgrade the Case Management database, go to Configure the Case Management
Database on MS SQL Server on page 88.

Use the Case Management Database screens to provide parameters required by the
Case Management Database.

Use the Case Management Database screen to enter the connection parameters for the
Case Management Database on Oracle.
To configure the Case Management Database on Oracle:

1. (Optional). On the Case Management Database screen, select Run the sql scripts
if you want the upgrade module to run the SQL scripts during the upgrade.
2. In the Case Management Database Properties section, enter the values as
Field Description

Case Management Database
Name (SID) Database system ID (SID) of the host where the Case
Management Database resides
Alias Name (TNS) TNS name of the Case Management Database

Field Description
3. In the Case Management Database Credentials section, enter the values as

Field Description
Case Management Applications Username User name for the core applications
Case Management Applications Password Password for the core applications
4. Click Next.
To configure the core applications, go to Configure the Core Applications on page 89.

On the Case Management Database screen, enter the connection parameters for the
Case Management Database on MS SQL Server.
To configure the Case Management Database on MS SQL Server:

1. (Optional). On the Case Management Database screen, select Run the sql scripts
if you want the upgrade module to run the SQL scripts during the upgrade.
2. In the Case Management Database Properties section, complete the fields as
Field Description
Host Host name or IP address of the host server used by the Case Management
Database
instance.
Instance Case Management Database instance.

This is an optional field. You must enter a value in this field only if you are
not using the default instance.
Name Name of the Case Management Database

Field Description
Schema Name of the Case Management Database schema
entry.
3. Enter the credentials for the Case Management Database in the fields, as described
Field Description
Administrator Username User name for the Case Management Database

administrator
Administrator Password Password for the Case Management Database

administrator
4. Enter the application user credentials for the Case Management application, as
web applications to connect to the Case Management Database.
Field Description
Case Management Application Username User name for the Case Management
application
Case Management Application Password Password for the Case Management

application
5. Click Next.
To configure the core applications, go to Configure the Core Applications on page 89.

Use the Core Applications screens to provide parameters required to connect the core
applications to the databases and the core application server.
The upgrade module only supports a dry-run mode for configuring the core
applications, where the .war files are saved for later use. After the upgrade module
finishes, you must manually deploy the web applications, as described in Deploy Web
Applications on page 108.



Use the Core Applications screen to enter the connection parameters for the
WebSphere application server.

1. In the Core Database Target Resource JNDI Name field, enter the name of the
JNDI used by theAdaptive Authentication application to connect to the Core
Database. The default value is PassMarkDB.
2. In the Application Server Properties section, in the Host field, enter the host
name or IP address of the host for the application server of the core applications.
4. Click Next.

Use the Core Applications screen to enter the connection parameters for the Tomcat
application server.

1. In the Core Database Global JNDI Resource Name field, enter the name of the
JNDI used by the AdaptiveAuthentication application to connect to the Core
Database. The default value is PassMarkDB.
Field Description
applications
8080)
3. Click Next.


Use the Core Applications screen to enter the connection parameters for the WebLogic
application server.

Adaptive Authentication application to connect to the Core Database. The default
Field Description
applications
7001)
4. Click Next.

Use the Core Applications screen to enter the connection parameters for the JBoss
application server.

Adaptive Authentication application to connect to the Core Database. The default
Field Description
applications
8080)
4. Click Next.


Using the Back Office Applications screens, provide parameters required to connect
the Back Office applications to the databases and the application server.
In Adaptive Authentication 7.1, the Configuration service manages all configuration
parameters in the Core Database. This requires all Back Office applications to be
connected to the Core Database.
On each application server or web container where you install any of the Back Office
applications, you must configure the Core Database datasource, PassMarkDB.

WebSphere application server.

2. In the Application Server Properties section, enter the host name or IP address
of the host for the application server of the Back Office applications.
4. Click Next.

Tomcat application server.

Authentication application to connect to the
Core Database. The default value is PassMarkDB
Back Office Database. The default value is PassmarkToolDB
Case Management Database. The default value is CMDB.


Field Description
Office applications
(usually 8080)
3. Click Next.

WebLogic application server.

environment if you want to modify the default JDBC URLs displayed in the
fields. The three fields include the URLs for the Core Database, the Back Office
Database, and the Case Management Database.
Field Description
Office applications
(usually 7001)
4. Click Next.


JBoss application server.

environment if you want to modify the default JDBC URLs that display in the
fields. The three fields include the URLs for the Core Database, the Back Office
Database, and the Case Management Database.
Field Description
Office applications
(usually 8080)
4. Click Next.
Review the Upgrade Parameters and Activate the Upgrade

The Upgrade Parameters Summary screen provides a summary of your selections in
the upgrade module. After you review the summary, you can activate the upgrade.
To activate the upgrade:

1. Review the upgrade parameters summary.
2. If the upgrade parameters do not meet your requirements, do the following:
a. Click Back on each screen until you reach the screen where you want to
change your entry or selection.
b. Change your entry or selection. You must re-enter and re-select entries if you
return to previous screens.
c. Click Next to continue to the Upgrade Parameters Summary screen.
3. If the upgrade parameters in the summary suit your requirements, click Upgrade
to proceed with the upgrade.
The upgrade begins. A series of progress screens indicate the progress of the
upgrade according to your selections in the upgrade module.

Review the Upgrade Summary

When the upgrade is complete, the Upgrade Summary screen provides a detailed
summary of the upgrade.
To review the upgrade summary:

1. Review the Upgrade Summary screen.
The summary includes the following information:
A link to the install.log file.
Note: If there are warning messages in the install.log file, you must
investigate these messages. For more information on resolving the warning
messages, see Troubleshooting After the Upgrade on page 95.
A link to the artifacts/webapps directory that contains .war files you can
deploy at a later time.
A link to the configurationUpgradeUtil.log file if you select Configuration
Migration on the Upgrade Components screen.
2. Click Finish to close the upgrade module.
Troubleshooting After the Upgrade

During the Adaptive Authentication (On-Premise) upgrade process, the Core database
is migrated seven days back from the upgrade date. There are warning messages that
may appear when running the upgrade on an Oracle database with partitions.
These warning messages appear only when:
Upgrading from versions prior to RSA Adaptive Authentication (On-Premise) 7.0
The customer is not running any maintenance tasks to automatically create or drop
partitions.
The warning messages are written to the core_scripts2.log file for each day of the
migration. The warning message appears as follows:
[Warning!] table <table_name> does not have a partition for
<migrated_date> day. No data would be migrated for this day.
where:
table_name refers to the table where the data is being migrated.
migrated_date is the date of the day the data was not migrated.

Investigate the Warning Messages

If the warning messages appear, you must investigate the causes for these warnings.
Procedure
1. Review the warning messages and their sources in the following log files:
install.log file
core_scripts2.log file
2. Check the REOT_IOT_MIGRATION_LOG table for additional information
about the causes of the warnings.
3. Take the following actions depending on the results of your investigation:
If you are not using Risk Engine data and not running the Risk Engine offline
tasks, ignore the warnings.
If you are using Risk Engine data and have not run the Risk Engine offline
tasks in the last seven days, the warnings must be resolved.
Resolve the Warning Messages

Perform the following the procedure to resolve the warning messages.
Procedure
1. Add partitions to the following tables:
ENTITY_AGGREGATIONS
REOT_EVENT_DYNAMIC_BUCKETS
REOT_EVENT_EXTRA_DATA
2. Run the Scheduler Risk Engine offline tasks. The Risk Engine offline tasks
recover the Risk Engine data not migrated in the last seven days.
For more information about the Scheduler Risk Engine offline tasks, see the
section Risk Engine Offline Tasks in chapter Scheduling RSA Adaptive
Authentication Tasks in the Operations Guide.
Note: The Risk Engine offline tasks take longer to run when recovering the data
not migrated during the last scheduled execution.
3. Activate server output, prior to running the SQL scripts, to display the messages
on the console.
4. Run the following SQL scripts:
66a_migration_offline_30.sql
66b_migration_offline_30.sql
5. Check the output of the scripts.
If no warning messages appear in the log file when running the scripts, the
recovery of the migrated data has completed successfully.
If warning messages appear in the log file, contact RSA for technical support.

Perform Post-Upgrade Tasks

After the upgrade module completes, you must perform the following tasks for the
upgrade to be successful:
Enable Partitions on an Oracle Database
Import Configuration Information into the Administration Console
Integrate the Authentication Plug-In Information from the Backup
Set Encryption
Import Configurations to the Database
Replace the Quartz Library in JBoss
Upgrade Client-Side Components
Update the deviceRecovery.drl File
Enable Partitions on an Oracle Database

If you have upgraded from RSA Adaptive Authentication (On-Premise) 6.0.2.1 on an
Oracle Database that uses partitions, you must enable partitions after the upgrade has
completed.
To enable partitions:
Run the following SQL script:
insert into GEN_CONFIG_PARAM
(ID,NAME,SECTION,REGION_CONTEXT,VERSION,CREATED,LASTMODIFIED)
values('1d2dce7bf91e4290aaf9cec72bcd2c7d','USING_DATABASE_PARTI
TIONS',5,'dummy',1,sysdate, systimestamp);
insert into GEN_CONFIG_PARAM_VALUE
(ID,GEN_CONFIG_PARAM_ID,VALUE)
values('766832da09cd4d208d3e0c3638a7709e','1d2dce7bf91e4290aaf9
cec72bcd2c7d','true');
Import Configuration Information into the Administration Console

This section describes the process by which the configuration information is moved to
the Back Office Administration Console.
Before You Begin

When you upgrade to RSA Adaptive Authentication (On-Premise) 7.1, passwords that
are in plain text before the upgrade are not encrypted after the upgrade. To resolve this
issue, update the password using the Back Office application and the password is
encrypted.
For instructions on updating the password, see the section Change your Password in
the chapter RSA Adaptive Authentication Back Office Applications in the Back
Office Users Guide.

To import the configuration information into the Administration Console:

1. Import the aaopConfigurationExportFileyyyyMMddHHmmss.xml file into the
This file is available in the
main_directory/utils_7.1.0.0.0\configuration-upgrade-71 folder.
2. Set the Risk Engine parameter Bank Region Country Code in the
Administration Console to the value of the countryCode property in the forensic
configuration file from earlier Adaptive Authentication (On-Premise) versions as
follows:
If you are upgrading from RSA Adaptive Authentication (On-Premise) 7.0,
extract the value from the countryCode property in the file
webapps\AdaptiveAuthentication\WEB-INF\classes\configs\d-config-for
ensic.xml .
If you are upgrading from a version earlier than RSA Adaptive Authentication
(On-Premise) 7.0, extract the value from the countryCode property in the file
<main_directory>\configs\c-config-forensic.xml.
Note: The Administration Console automatically sets the parameter Bank

Region Country Code to the default value US.
For more information about the Bank Region Country Code parameter, see the
section about general Risk Engine parameters in the chapter Administration
Console in the Operations Guide.
3. Restart the Adaptive Authentication system.
Integrate the Authentication Plug-In Information from the Backup

To manually integrate Authentication Plug-In information from the backup with
the Adaptive Authentication (On-Premise) applications:
1. Copy the Web Services extensions (*.xsd files) added as part of Authentication
Plug-In development effort to the AdaptiveAuthentication/WEB-INF/services
directory. This change should also be reflected in the AcspImport.xsd file.
2. Copy the Authentication Plug-In byte code to the
AdaptiveAuthentication/WEB-INF/lib directory.
3. Copy the Authentication Plug-in configuration to the Adaptive Authentication
configuration directory. If applicable, you must copy the configuration to the
Adaptive Authentication Admin configuration directory.
For more information on Authentication Plug-In development, see the
Authentication Plug-In Developers Guide.

Set Encryption
To set the encryption after the upgrade:
1. Copy the c-config-security.xml file from backup to the encryption utility.
2. Run the encryption utility in the rotate mode using the c-config-security.xml file
restored from backup.
The encryption utility decrypts the seeds and re-encrypts them using the new
encryption algorithm that has been changed in the new software version.
3. Copy the new c-config-security.xml file generated by the encryption utility to the
following locations:
AdaptiveAuthentication/WEB-INF/classes
AdaptiveAuthenticationAdmin/WEB-INF/classes
casemanagement/WEB-INF/classes
scheduler/WEB-INF/classes
backoffice/WEB-INF/classes
aggDeviceToken/WEB-INF/classes
Import Configurations to the Database

If you had your configurations in the database in the previous installation, and want to
retain all the configurations in the database, you must use the ConfigTool from the 7.1
utilities folder to import the remaining configurations from the configs folder to the
database.
Replace the Quartz Library in JBoss

JBoss 5.1 ships with Quartz 1.5.2, which is not compatible with the code used in the
Adaptive Authentication Scheduler application. If you are upgrading to RSA Adaptive
Authentication (On-Premise) 7.1 on a JBoss application server, you must replace the
Quartz library in JBoss with the library provided with the Scheduler distribution
package.
To replace the Quartz library in JBoss:

1. After you complete the dry run of the upgrade module, navigate to the
scheduler.war/WEB-INF/lib directory, and copy the quartz-all-1.6.1.jar file to
the common/lib directory of JBoss.
2. Delete the common/lib/quartz.jar file in the JBoss installation directory.
Note: For more information on why the obsolete Quartz version could cause
problems, see https://jira.jboss.org/browse/JBAS-6133.

Upgrade Client-Side Components

Ensure that you integrate the JavaScript code and the flash component from the
WebResources package into your web applications. For more information, see Install
Updated Web Resources Files on page 154.
Update the deviceRecovery.drl File

Due to the upgrade to Drools 5, if you modified the deviceRecovery.drl file in
previous versions, you must manually update the code in these files to comply with
the new version.

For instructions about copying external data provider files, see Copy External Data
Provider Files on page 54.
Enable Mobile Application Protection

If you implemented mobile application protection in RSA Adaptive Authentication
(On-Premise) 6.0.2.1 SP2 or RSA Adaptive Authentication (On-Premise) 6.0.2.1 SP3,
you must enable the Mobile Protection Enable Mobile Application in Mode 0
parameter after you upgrade. If you do not activate the mobile flag, you might see a
change in the risk score, which will effect the challenge rate.
For more information about enabling mobile protection, see the section about
configuring risk engine parameters in the Operations Guide.
Configure Authentify Settings

After upgrading, you need to update your Authentify settings in the
c-authentify-requestResource.auth file, located in the configs folder of your
To configure Authentify settings:

1. Open the c-authentify-requestResource.auth file in a text editor.
2. Copy the values from the backup c-authentify-requestResource.auth file you
created before upgrading to the current file.
Note: The following changes were made in the c-authentify-requestResource.auth

file for this version:
The password field is now labeled license key. To obtain a license key, contact
your RSA representative.
The following fields were removed:
bank_id
from_account_query_format
number_of_digits_in_identifier
identifier_name
identifier_desc

identifier_query_format
identifier_value
forwarding_number
request_type
3. Save the file.

6 Complete a Dry-Run Upgrade

Run SQL Scripts
Check the Installation of Back Office Applications
Check the Database Upgrade
This chapter describes the tasks that you must perform to complete the upgrade if you
chose to do a dry-run of the upgrade, that is, you did not select to run the sql scripts
automatically when configuring the databases.
Run SQL Scripts

Before running the SQL scripts, ensure that you have performed the preparations for
the upgrade. For the more information, see Upgrade Prerequisites on page 65.
Note: While running the SQL scripts, verify that no warnings were issued during the
Core database upgrade. For more information, see Troubleshooting After the Upgrade
on page 95.
Manually run the SQL scripts in numerical order according to their filenames. For
more information about the scripts to run, refer to:
SQL Scripts for MS SQL Server
Note: Activate server output when running the SQL scripts to display application
messages on the console.
6: Complete a Dry-Run Upgrade 103


The following table lists the SQL scripts that you must run for the Core, Back Office,
and Case Management Databases.
Important: You must run a script only if you are upgrading directly from the version
of RSA Adaptive Authentication (On-Premise) specified in the Previous Version
column. Do not run a script if you are upgrading directly from a version other than the
version specified in the Previous Version column.
Previous
Sql Script Credential Database
Version
48_Patch_9_core.sql 7.0 DBA user Core
49_Patch_9_aa_model.sql 7.0 DBA user Core
54_SP3_db_changes .sql 6.0.2.1 SP2 schema user Core

Back Office
Case Management
55_SP3_CRE_changes.sql 6.0.2.1 SP2 schema user Core
60_AA71_db_changes.sql 6.0.2.1 SP2 schema user Core

6.0.2.1 SP3 Back Office
Case Management
62_db_CRE_30_changes.sql 6.0.2.1 SP2 schema user Core

6.0.2.1 SP3
62_Drop_RSA_HTTP_SESSION.sql 6.0.2.1 SP2 schema user Core

6.0.2.1 SP3
7.0
63_Long_Auth_db_changes.sql 6.0.2.1 SP2 schema user Core

6.0.2.1 SP3
7.0
64_UpgradePMObjects_2.sql 6.0.2.1 SP2 schema user Core

6.0.2.1 SP3
65a_21_to_251_AddModelColumnToEventLog. 6.0.2.1 SP2 schema user Core

sql 6.0.2.1 SP3
65b_251_to_30_AddModelColumnToEventLog. 6.0.2.1 SP2 schema user Core

sql 6.0.2.1 SP3
66a_migration_offline_30.sql 6.0.2.1 SP2 schema user Core

6.0.2.1 SP3
104 6: Complete a Dry-Run Upgrade

Previous
Version
66b_migration_offline_30.sql 6.0.2.1 SP2 schema user Core

6.0.2.1 SP3
67_mobile_categories_migration_upgrade.sql 6.0.2.1 SP2 schema user Core

6.0.2.1 SP3
80_CreateCREData.sql 6.0.2.1 SP2 schema user Core

6.0.2.1 SP3
7.0
91_CreateCREData_upgrade.sql 6.0.2.1 SP2 schema user Core

6.0.2.1 SP3
7.0
92_CreateCREData_nongenerated.sql. 6.0.2.1 SP2 schema user Core

6.0.2.1 SP3
94_CreateCREData_general.sql 6.0.2.1 SP2 schema user Core

6.0.2.1 SP3
7.0
97_CreateCREData_maxmind.sql 6.0.2.1 SP2 schema user Core

6.0.2.1 SP3
7.0
981_Grant_Privileges.sql 6.0.2.1 SP2 schema user Core

7.0 Case Management
982_APP_Synonyms_changes.sql 6.0.2.1 SP2 application user Core

7.0 Case Management
99_APP_UpdateDbVersion.sql 6.0.2.1 SP2 application user Core

7.0 Case Management

SQL Scripts for MS SQL Server

The following table lists the SQL scripts that you must run for the Core, Back Office,
and Case Management Databases.
Important: You must run a script only if you are upgrading directly from the version
of RSA Adaptive Authentication (On-Premise) specified in the Previous Version
column. Do not run a script if you are upgrading directly from a version other than the
version specified in the Previous Version column.
Previous
Version
48_Patch_9_core.sql 7.0 DBA user Core
49_Patch_9_aa_model.sql 7.0 DBA user Core
54_SP3_db_changes .sql 6.0.2.1 SP2 DBA user Core

Back Office
Case Management
55_SP3_CRE_changes .sql 6.0.2.1 SP2 DBA user Core
60_AA70_db_changes.sql 6.0.2.1 SP2 DBA user Core

Case Management
61_AA71_db_changes.sql 6.0.2.1 SP2 DBA user Core

6.0.2.1 SP3
7.0
62_db_CRE_30_changes.sql 6.0.2.1 SP2 DBA user Core

6.0.2.1 SP3
62_CM_db_changes.sql 6.0.2.1 SP2 DBA user Case Management

6.0.2.1 SP3
7.0
62_Drop_RSA_HTTP_SESSION.sql 6.0.2.1 SP2 DBA user Core

6.0.2.1 SP3
7.0
64_UpgradePMObjects_2.sql 6.0.2.1 SP2 DBA user Core

6.0.2.1 SP3
65a_21_to_251_AddModelColumnToEventLog. 6.0.2.1 SP2 DBA user Core

sql 6.0.2.1 SP3

Previous
Version
65b_251_to_30_AddModelColumnToEventLog. 6.0.2.1 SP2 DBA user Core

sql 6.0.2.1 SP3
66a_migration_offline_30.sql. 6.0.2.1 SP2 DBA user Core

6.0.2.1 SP3
67_mobile_categories_migration_upgrade 6.0.2.1 SP2 DBA user Core

6.0.2.1 SP3
80_CreateCREData.sql 6.0.2.1 SP2 DBA user Core

6.0.2.1 SP3
7.0
90_AA_13949.sql 6.0.2.1 SP2 DBA user Core

6.0.2.1 SP3
7.0
91_CreateCREData_upgrade.sql 6.0.2.1 SP2 DBA user Core

6.0.2.1 SP3
7.0
92_CreateCREData_nongenerated.sql 6.0.2.1 SP2 DBA user Core

6.0.2.1 SP3
94_CreateCREData_general.sql 6.0.2.1 SP2 DBA user Core

6.0.2.1 SP3
7.0
97_CreateCREData_maxmind.sql 6.0.2.1 SP2 DBA user Core

6.0.2.1 SP3
7.0
981_Grant_Privileges.sql 6.0.2.1 SP2 DBA user Core

7.0 Case Management
99_APP_UpdateDbVersion.sql 6.0.2.1 SP2 Application user Core

7.0 Case Management

Important: Do not install the Scheduler, the Back Office, and the Adaptive
Authentication applications on the same application server or web server.
Before You Begin

The size of the physical memory in an application server is configured in the startup
script of that application server. The startup scripts for the supported application
servers are as follows:
For WebSphere: startServer.sh
For JBoss: run.sh
For Tomcat: startup.sh
For WebLogic: startWeblogic.sh
Procedure
1. If your application server is running a UNIX-based operating system, set the size
of the physical memory in your application server to unlimited.
2. Update the startup scripts by adding the following command according to the
operating system running on your application server.
On AIX, add the command:
ulimit -m unlimited
On Solaris and Linux, add the command:
ulimit -v unlimited
Deploy Web Applications on Tomcat

To deploy the web applications on the Tomcat application server:
1. Stop the server.
2. Remove the web applications for the previous version. Make sure that you clean
any cache and temporary folders in the application server that may contain
references to the web applications from the previous version.
3. Locate the configured .war files in the artifacts<Time_Date>/webapps directory
in the upgrade directory.
4. Deploy the .war files and start the server.

Deploy Web Applications on WebSphere

To deploy the web applications on the WebSphere application server:
1. Uninstall all the web applications for the previous version. Make sure that you
clean any cache and temporary folders in the application server that may contain
references to web applications for the previous version.
a. In the WebSphere Administrative Console, navigate to the Enterprise
Applications page.
b. Select all of the web applications that you want to remove and click
Uninstall.
c. Confirm your choice and click OK.
d. When prompted, click Save to save the changes to the master configuration.
2. Create an additional work manager with a JNDI name, wm/offlineTask:
Configure a minimum threads parameter for the wm/offlineTask work
manager to be 10.
Set the Growable parameter for the work manager to False.
While deploying the Adaptive Authentication and the Scheduler web applications,
when prompted to select a work manager:
For the Adaptive Authentication web application, select the default work
manager, wm/default.
For the Scheduler web application, select both the default work manager,
wm/default, and the Offline Tasks dedicated work manager, wm/offlineTask.
3. Install the .war files in the WebSphere Administrative Console.
a. Navigate to the Enterprise Application page and click Install.
b. Select the Remote file system radio button and click Browse.
c. Enter the location of the configured .war files in the artifacts/webapps
directory in the upgrade directory.
d. Select the radio button for the application that you are installing, for example,
AdaptiveAuthentication.war, and click OK.
e. In the Select installation options page, under the Application name field,
delete the _war from the application name and click Next.
f. In the Map modules to servers page, accept the defaults and click Next.
g. In the Map resource references to resource page, set relevant datasources,
according to the JDBC datasources that you created. Click Next.
The JNDI name is usually the same as the resource reference name.
h. In the Map virtual hosts for Web modules page, click Next.
i. In the Map context roots for Web modules page, enter the .war filename
without the .war extension, and click Next.
For example, in the case of Case Management, enter casemanagement in
the Context Root field.

j. On the Summary page, click Finish.

4. Ensure that the class loader order is set to Classes loaded with application class
loader first (parent last). For more information, see Setting the Class Loader
Order on page 53.
Deploy Web Applications on WebLogic

1. Undeploy the web applications from the previous version. Make sure that you
clean any cache and temporary folders in the application server that may contain
references to the web applications from the previous version.
upgrade directory.
3. Extract the contents of the .war file onto the file system.
4. Deploy the .war files in the WebLogic Adsministration Console.
5. You must create an additional Work Manager named wm/offlineTask. You must
set a new minimum threads constraint to 10 and associate it with the
wm/offlineTask Work Manager.
For information on creating a work manager, refer to the WebLogic user manual.
Deploy Web Application on JBoss

upgrade directory.
2. Extract the contents of the .war files onto the file system in the directory where the
applications are deployed.
Tasks After Web Application deployment

The following are tasks to do after the web applications are deployed on the JBoss
application server.
When you install the Scheduler on the JBoss application server, you must define a
new thread pool OfflineTaskThreadPool with default settings dedicated to
offline tasks.
For more information, see Configure a Separate Work Manager for RSA Risk
Engine Offline Tasks on page 125.
If you deploy the web applications on JBoss manually, you must ensure that the
web application directory ends with the suffix .war, for example,
server/default/deploy/AdaptiveAuthentication.war.

When you deploy the Adaptive Authentication application on JBoss, you must
specify an absolute path for the CSS File and Logo File parameters in the
Update the absolute path for the parameters in the Out-Of-Band E-mail section of
the Authentication Methods component in the Administration Console as follows:
The absolute path for the E-mail - CSS File parameter
JBOSS_HOME/server/default/deploy/AdaptiveAuthenticatio
n.war/css
The absolute path for the E-mail - Logo File parameter
JBOSS_HOME/server/default/deploy/AdaptiveAuthenticatio
n.war/images

To check the installation of the core applications that you selected during the upgrade,
run the health checks using the HealthCheckServlet. The HealthCheckServlet requires
you to provide the Web Services credentials which are the access credentials for the
core applications.
To run the health checks:

1. Navigate to http://host:port/AdaptiveAuthentication/healthCheck.
2. Enter your caller credentials in the log on screen.
You are redirected to the HealthCheck results page. The HealthCheck results page
displays a table which provides the following information:
Each module that is validated
Results for each module that is validated
Note: The first time you run the Health Check Servlet after the upgrade, the Risk
Engine Health Check task, scheduled to run daily at midnight, has not run yet. A
warning message appears to explain that there is no information on the Risk Engine
tasks.
Check the Installation of Back Office Applications

To verify the installation of the Back Office applications that you selected during
the upgrade:
1. Open each Back Office application, in any order, to make sure they are
functioning correctly.
2. Log on to the Back Office applications.
In the user name field, type admin.

In the password field, type the password that you configured in RSA Adaptive
Authentication (On-Premise) 6.02.1 SP2.
For a list of URLs that you can use to log on to the different Back Office applications
and the actions that you can perform to check if the applications function correctly,
refer to Checking the Installation of Back Office Applications on page 61.
Check the Database Upgrade

RSA recommends that you run a database schema verification to verify the database
schema integrity after the upgrade. For more information, see the Diagnostics
Manager Users Guide.

7 Configure Adaptive Authentication

Applications
The Aggregator Token Application
Configure the RSA Risk Engine
Configure a Separate Work Manager for RSA Risk Engine Offline Tasks
Secure the Data Source Password for Tomcat
Configure the Web Services Author Application
Configure the log4j.properties File
Shared Configuration Information in a Distributed Environment
This chapter describes how to configure the applications in the RSA Adaptive
Authentication (On-Premise) system.

This section describes how to configure the following Core applications:
Adaptive Authentication
Adaptive Authentication Admin
Scheduler
Configure the Adaptive Authentication Application

If user credential encryption is enabled, restore the c-config-security.xml file, from
the backup folder that you created before the upgrade, to the WEB-INF/classes/
folder for the AdaptiveAuthentication application.
7: Configure Adaptive Authentication Applications 113

The following table lists the files that you must configure for theAdaptive
Authentication application.
Path and Filename Variable Value Procedure
AdaptiveAuthentication/WEB-INF/classes/ log4j.appender.LOGFILE.File Path to location of

log4j.properties log file
log4j.appender.RE_LOGGER.File
log4j.appender.auditor.File
log4j.appender.alarm.File
log4j.appender.forensic.File
log4j.appender.failedChallenge.File
log4j.appender.failedChallenge.Encoding
log4j.appender.HIBERNATE.File
AdaptiveAuthentication/WEB-INF/web.xml loadLocalConfigsOnly Set to true if you only

intend to use the file
system for
configurations.
Set to false if you
(also) intend to use
the database for
configurations.
localFilesBasePath Relative path from Set to blank if you

WEB-INF/classes only intend to use the
folder or absolute database.
path to folder for
configurations
secondaryBasePathList This path can be The directory where

relative to the class the external files
path (classes required for the
directory) or an Configuration
absolute path Framework reside.
configTreeName Label used for

configurations tree
AdaptiveAuthentication/WEB-INF/classes/ db.vendor Database vendor

config.properties used
db.schemaName Database schema

name
db.creVendor Uncomment the lines

that are relevant to
your database
environment (Oracle
or MS SQL)
114 7: Configure Adaptive Authentication Applications

Note: The upgrade module adds the geoip_SHORTRUN_1.dat file in the

AdaptiveAuthentication/WEB-INF/classes/configs folder after the upgrade. This
file is a demo file for a Maxmind geoIP file that you can use if you do not have the
official Maxmind geoIP database file. You can ignore this file.
Configure the Adaptive Authentication Administration Application

If user credential encryption is enabled, you must restore the c-config-security.xml
file, from the backup folder that you created before the upgrade, to the
WEB-INF/classes/ folder for the Adaptive Authentication Administration
application.
The following table lists the files that you must configure for the
AdaptiveAuthenticationAdmin application.
AdaptiveAuthenticationAdmin/WEB-INF/classes/log4j.pro log4j.appender.LOGFILE.File Path to location of

perties log file
log4j.appender.HIBERNATE.
File
AdaptiveAuthenticationAdmin/WEB-INF/classes/config.pr db.vendor Database vendor

operties used

name
db.creVendor Uncomment the

lines that are
relevant to your
database
environment
(Oracle or MS
SQL)

Configure the Scheduler

You can customize the log4j.properties and database.properties files, located under
scheduler/WEB-INF/classes, for the tasks given in the following table.
Path and Filename Variable Value
scheduler/WEB-INF/classes/log4j.properties Case Management log4j.appender.CMLOGGER.File=CSG@RSA_

ServerName@DataCenterName_case.log
Case Management Events log4j.appender.CMEVENTSMARKINGLOGGER.

Marking File=CSG@RSA_ServerName@DataCenterName_
eventsmarking.log
Monitoring and Alerts log4j.appender.ALERTLOGGER.File=CSG@RSA_

ServerName@DataCenterName_alarm.log
Billing log4j.appender.billlogger.File=logs/CSG@RSA_
ServerName@DataCenterName_billing.log
OOB Billing log4j.appender.oobbilllogger.File=logs/CSG@RSA_

ServerName@DataCenterName_acspBilling.log
log4j.appender. The location of the log files.

ALERTLOGGER.File
log4j.appender.LOGFILE.File
scheduler/WEB-INF/classes/database.properties cm.schema The name of the schema for the CM database.
aa.schema The name of the schema for the AA database.
CMDBType The vendor of the CM database. Possible values are:

Oracle
MS SQL
AADBType The vendor of the AA database. Possible values are:

Oracle
MS SQL
cm.logger.org


This section describes how to configure the following Back Office applications:
Access Management
Back Office
Case Management
Report Viewer
Web Service Credentials Manager
Aggregate Device Token
Configure the Access Management Application

The following table lists the files that you must configure for the Access Management
application.
accessmanagement/WEB-INF/classes/log4j.properties log4j.appender.LOGFILE.File Path to location of

log file
log4j.appender.auditor.File Path to location of

log file
accessmanagement/WEB-INF/classes/config.properties db.vendor Database vendor

used

name

lines that are
relevant to your
database
environment
(Oracle or MS
SQL)

Configure the Case Management Application

The following table lists the files that you must configure for the Case Management
application.
casemanagement/WEB-INF/classes/database.properties cm.schema Schema of Case

Management
Database
aa.schema Schema of Core

Database
CMDBType Database type for

Case Management
Database
AADBType Database type for

Core Database
casemanagement/WEB-INF/classes/log4j.properties log4j.appender.CMLOGGER. Path to location of

File log file
log4j.appender.CMEVENTSM
ARKINGLOGGER.File
casemanagement/WEB-INF/classes/config.properties db.vendor Database vendor

used

name

lines that are
relevant to your
database
environment
(Oracle or MS
SQL)
Configure the Common Files

Common files generated by the Case Management application contain:
Updated status of cases
Lists of events and their resolutions in the Case Management system
To configure the common files:

1. Modify the paths for the following log files:
casemanagement.log
eventsmarking.log
casemanagement.audit.log

2. Update the names of the log files to correspond with the names of the latest log
files generated by the Case Management application.
For example, modify the eventsmarking.log filename property according to the
following file naming format:
<OrgName>@<InstitutionName>_<ServerName>@<DataCenterName>
_eventsmarking.log
An example of the file name revised according to the naming format:
log4j.appender.CMEVENTSMARKINGLOGGER.File=SmallLakeCU@RSA
Customer_RSA1@MenloParkDC_eventsmarking.log
3. Save the modified log files.
Configure the Back Office Application

The following table lists the files that you must configure for the Back Office
application.
backoffice/WEB-INF/classes/log4j.properties log4j.appender.LOGFILE.File Path to location of

log file
log4j.appender.AUDITOR.File
log4j.appender.LOGIN_AUDITOR.File
log4j.appender.PM_AUDITOR.File
log4j.appender.AC_AUDITOR.File
log4j.appender.CSR_AUDITOR.File
backoffice/WEB-INF/classes/config.properties db.vendor Database vendor Uncomment the

used lines that are
relevant to your
database
environment
(Oracle or MS
SQL)

name
db.creVendor Database vendor Uncomment the

used lines that are
relevant to your
database
environment
(Oracle or MS
SQL)

Configure the Report Viewer Application

The following table lists the files that you must configure for the Report Viewer
application.
reportviewer/WEB-INF/classes/log4j.properties log4j.appender.LOGFILE.File Path to location of

log4j.appender.auditor.File log file
reportviewer/WEB-INF/web.xml reportsRootPath Path to report

folder
reportTypeList Report types that a

user could see in the
Report Viewer.
reportNameList Report names that a

user could see in the
Report Viewer.
caseSensitiveFilenames Determines if
document names are
case-sensitive.
reportviewer/WEB-INF/classes/config.properties db.vendor Database vendor

used

name

lines that are
relevant to your
database
environment
(Oracle or MS
SQL)

Configure the Web Service Credentials Manager Application

The following table lists the files that you must configure for the Web Service
Credentials Manager application.
wscredentialmanager/WEB-INF/classes/log4j.properties log4j.appender.LOGFILE.File Path to log file
log4j.appender.auditor.File Path to log file
wscredentialmanager/WEB-INF/classes/configs.properties db.vendor Database vendor

used

name

lines that are
relevant to your
database
environment
(Oracle or MS
SQL)
The Aggregator Token Application

Account aggregators enable a customer with online services to allow an aggregation
application to access the online services on behalf of the customer. For example, a user
logs on to an aggregator token recognized by RSA and is automatically logged on to
an organization service.
For an aggregator to access your online service, you need to define a list of authorized
IP addresses. In addition to these authorized IP addresses, the Adaptive Authentication
application allows for the definition of specific aggregator tokens.
For an aggregator to be able to log on as a user, an authorized IP address and the
associated aggregator token must be present.
When Adaptive Authentication receives a logon request from an IP address associated
with an aggregator, the application checks for the presence of an aggregator token
assigned to an IP address or range of IP addresses authorized by the aggregator.
The result is one of the following:
If the aggregator token is present and the IP address is included in the list of
authorized IP addresses for that aggregator, the logon is allowed.
If the aggregator IP address is authorized, but the associated aggregator token
does not match the device ID for the device associated with the aggregator token,
the user is challenged.
If the aggregator token is present, but the IP address is not included in the list of
authorized IP addresses for that aggregator, the user is challenged.

It is important to be aware of the following facts about aggregator tokens:

An aggregator token can be associated with one or more of the following:
a single IP address
a group of IP addresses
a range of IP addresses
An aggregator can create and maintain multiple aggregator tokens.
An aggregator alias represents a group of authorized IP addresses listed in the
aggregation configuration file, c-config-aggregation.xml.
An aggregator alias must begin with the prefix agg-.
For example:
agg-company-US1
agg-company-US2
This prefix allows Adaptive Authentication to identify a device token as an
aggregator token.
Configure the Aggregator Token Application

Perform the following procedures to configure your application for the aggregator
token application, aggDeviceToken.
Define Aggregator Information

The following procedure describes how to generate an initial aggregator token before
configuring for aggregators.
Before You Begin

1. Determine the specific IP addresses authorized by each aggregator.
2. Identify the aggregator tokens used by each aggregator.
3. For each device, retrieve the deviceID and list of IP addresses from which each
device is allowed to be used.
Procedure
1. Add the IP address of the computer from which you are generating the aggregator
token to the list of authorized IP addresses in the c-config-aggregation.xml file.
Note: To allow for the initial entry of the IP address, remove this IP address from
the list prior to working in Production.
2. Remove any device tokens or cookies from the browser in use on your system.
The GetDeviceTokenServlet servlet attempts to verify if the device tokens or
cookies are aggregator tokens.

Configure Aggregator Access

Configure the Adaptive Authentication application to allow aggregators access to a
user account without the system performing a device check.
Each time the aggregator changes the IP address from which it connects to a user
account, you must update the IP address in the c-config-aggregation.xml file.
Procedure
1. Locate the WEB-INF/Classes/configs directory of the installation.
2. Open the file c-config-aggregation.xml in a text editor.
3. In the file c-config-aggregation.xml, specify the IP address used by the supported
aggregator as follows:
a. Find the entry in c-config-aggregation.xml.
<property name="deviceIps">
<list>
<value>IP address1</value>
</list>
</property>
b. Create entries for each IP address under the property deviceIPs. Use the
following format to specify a single IP address or a range of addresses.
<property name="deviceIps">
<list>
</list>
</property>
c. Specify the aggregator tokens assigned to your supported aggregators.
d. Find the entry in c-config-aggregation.xml.
<property name="deviceId">
<value>IP address group name</value>
</property>
where IP address group name is the name of the list of authorized IP
addresses you want to associate with the aggregator token for the device.
e. Create an entry for the device token that is assigned to the IP addresses
specified using in this procedure.
4. Repeat the previous steps in this procedure for the c-config-aggregation.xml files
located in the installation directory. The default installation directory is
c:/rsa/configs.

Define an Aggregator Token

Issue a getDeviceToken Soap method with the device you want to associate with an
aggregator token. An aggregator token is returned, defined for the IP addresses
represented by the aggregator alias.
Before You Begin

Ensure that the aggregator information is configured during installation. For more
information, see Define Aggregator Information on page 122.
Procedure
1. In your web browser, enter the following URL:
http://server:port/aggDeviceToken/getDeviceToken?deviceID
=aggregator_alias&
username=your_username&password=your_password
where:
deviceID is the identification of the device to be associated with the
aggregator token.
aggregator_alias is the list of authorized IP addresses.
your_username and your_password are your user credentials.
Note: If the URL is entered without an aggregator alias, the device token returned
is associated with all the IP addresses in the aggregation configuration file.
2. When you enter the aggregator alias, an error or null message may appear in the
following cases:
If the aggregator alias you entered is not defined in the configuration file,
check the spelling of the aggregator alias.
If there is an invalid parameter in the URL command line, a null message
appears.

Configure the RSA Risk Engine

All changes to the Risk Engine configuration need to be made to the Risk Engine
parameters using the Back Office Administration Console.
You can edit the following General Risk Engine parameters in the Administration
Console:
Number of Threads. The number of concurrent threads that are available in the
thread pool for the Work Manager resource in an application server.
Enable Bayesian Grouping. If you have multiple organizations that may contain
multiple business entities and multiple types of behavior, you must create a risk
analysis for each organization.
If you set the Enable Bayesian Grouping parameter to True, the Risk Engine
considers each organization as a different business. Separate statistical data is
created for every organization.
Enable Profiles Migration. A Boolean parameter that indicates whether or not to
allow the migration of the database structure profiles.
Trojan Attack Risk Score Threshold. The risk score from which a process is
triggered to verify if a Trojan attack is occurring for a specific transaction.
For more information about these and the other Risk Engine parameters, see the
section Risk Engine Parameters in the Administration Console chapter of the
Operations Guide.
Configure a Separate Work Manager for RSA Risk Engine Offline

Tasks
Risk Engine offline tasks perform lengthy batch processing tasks that are scheduled on
a daily basis. During this processing, the Risk Engine offline tasks require multiple
worker threads to be activated. The Work Manager initiates worker threads in the
application servers.
In releases of RSA Adaptive Authentication (On-Premise) earlier than 6.0.2.1 SP3,
the Work Manager resource was shared by the Scheduler service and the Risk Engine
offline tasks. If the Risk Engine offline tasks exceed the number of concurrent threads,
the scheduled jobs are put on hold.
To prevent this behavior, a separate Work Manager resource dedicated to Risk Engine
offline tasks is introduced in RSA Adaptive Authentication (On-Premise) 6.0.2.1 SP3
and later versions.

You must set the name of the Work Manager in the WebSphere and WebLogic
application server to be wm/offlineTask.
For WebLogic, you must generate a new minimum threads constraint and
associate it with the wm/offlineTask Work Manager.
For more information on configuring the Work Manager for your application
server, see the appropriate application server manual.
For JBoss, you must define a new thread pool OfflineTaskThreadPool with
default settings dedicated to offline tasks.
For example, the JBOSS_HOME\server\default\deploy\jca-jboss-beans.xml
file is as follows:


<bean name="OfflineTaskThreadPool"
class="org.jboss.util.threadpool.BasicThreadPool">

<annotation>@org.jboss.aop.microcontainer.aspects.jmx.
JMX(name="jboss.system:service=OfflineTaskThreadPool",
exposedInterface=org.jboss.util.threadpool.
BasicThreadPoolMBean.class)
</annotation>

<property name="name">OfflineTaskThreadPool</property>

<property name="maximumQueueSize">1024</property>

<property name="maximumPoolSize">100</property>

<property name="minimumPoolSize">10</property>

<property name="blockingMode">wait</property>

<property name="keepAliveTime">60000</property>
</bean>
Note: Do not change the value of the name property. It must be

OfflineTaskThreadPool.
Secure the Data Source Password for Tomcat

Database passwords are kept in clear text in the Tomcat server.xml file. If you want to
obfuscate the passwords in the server.xml file, you must use the data source password
obfuscation package that is available after you install Adaptive Authentication.
Important: The initialSize parameter is not supported if you are using the data source
password obfuscation package for Tomcat.

To secure the data source passwords in the server.xml file:

1. Select the Utilities component during installation.
2. Unzip the main directory\utils_7.1.0.0.0\tomcat-ds-password-obfuscation.zip
file to the Tomcat server library directory, tomcat-home/conf.
3. Edit the server.xml file and change the relevant data sources to use the password
encrypting factory.
For example, change the data source xml element from:
<Resource ... name="jdbc/PassmarkDB" ...
password=password-in-clear-text.../>
to:
<Resource ... name="jdbc/PassmarkDB"
factory="com.rsa.aaop.security.ObfuscatedPasswordDataSour
ceFactory" ... password=password-in-clear-text.../>
4. Restart Tomcat.
Note: If you are using Tomcat shell scripts to start Tomcat, you must run the
scripts from the CATALINA_HOME directory and not from the
CATALINA_HOME\bin directory. For example, on Windows you must run
bin\startup.bat from the CATALINA_HOME directory.
After you have secured the data source password, the password appears in the
server.xml file, as shown:
<Resource ... name="jdbc/PassmarkDB"
factory="com.rsa.aaop.security.ObfuscatedPasswordDataSourceFact
ory" ...
password="{PBE}nc5dEYCat865ftI4LExmb+ioxSZLSu3I".../>
Change a Secure Database Password

If you change your database password, you must update the server.xml file with the
new password in clear text. Ensure that you remove the {PBE} prefix. The new
password is encrypted after you restart Tomcat.
Change the Encryption Scheme

The obfuscation function is not a complete encryption solution. The obfuscation
function uses MD5 and DES algorithms and the Jasypt library with a seed that is
stored in the code. You can replace the seed generation scheme or the encryption and
decryption schemes.
To replace the seed generation scheme:

1. Create a class that extends
com.rsa.aaop.security.ObfuscatedPasswordDataSourceFactory$
SimplePasswordGenerator that is available in the .jar file,
tomcat-ds-password-obfuscation-nnnn.jar.
where nnnn is the version of Adaptive Authentication (On-Premise) that you have
installed.

2. Override the generatePassword() method with your seed generation algorithm.

This method should always return the same seed.
3. Pack your code as a .jar file and copy it along with any required third-party library
to the Tomcat library directory.
4. Restart Tomcat.
To replace the entire password encryption and decryption schemes:

1. Create a class that implements com.rsa.aaop.security.PasswordGenerator that
is available in the jar file, tomcat-ds-password-obfuscation-nnnn.jar.
where nnnn is the version of Adaptive Authentication (On Premise) that you have
installed.
2. Override the generatePassword() method with your seed generation algorithm.
This method should always return the same seed.
3. Override the encrypt(BasicDataSource ds) method with your encryption
algorithm.
This method should encrypt the given password and update the datasource.
4. Override the decrypt(BasicDataSource ds) method with your decryption
algorithm.
This method should decrypt the given password and update the datasource.
5. Ensure that the isEncrypted(String password) method indicates whether the given
password is encrypted or in clear text.
6. Pack your code as a .jar file and copy it along with any required third-party library
to the Tomcat library directory.
7. Restart Tomcat.
Encryption from the Command Line

Encryption is performed at the command line using the encrypt.bat or encrypt.sh
command. All the default values of this encryptor class are assumed when executing
the CLI command.
Usage:
$ ./encrypt.sh
USAGE: encrypt.sh [ARGUMENTS]
* Arguments must apply to format:
"arg1=value1 arg2=value2 arg3=value3 ..."
* Required arguments:
input
password
Example:
$ ./encrypt.sh input="This is my message to be encrypted"
password=password
----ENVIRONMENT-----------------
Runtime: Sun Microsystems Inc. Java HotSpot(TM) Client VM
1.6.0_03-b05

----ARGUMENTS-------------------
input: This is my message to be encrypted
password: password
----OUTPUT----------------------
k1AwOd5XuW4VfPQtEXEdVlMnaNn19hivMbn1G4JQgq/jArjtKqryXksYX4Hl
6A0e
Decryption from the Command Line

Decryption is performed at the command line using the decrypt.bat or decrypt.sh
command. All the default values of this encryptor class are assumed when executing
the CLI command.
Usage:
$ ./decrypt.sh
USAGE: decrypt.sh [ARGUMENTS]
* Arguments must apply to format:
"arg1=value1 arg2=value2 arg3=value3 ..."
* Required arguments:
input
password
Example:
$ ./decrypt.sh
input="k1AwOd5XuW4VfPQtEXEdVlMnaNn19hivMbn1G4JQgq/jArjtKqryX
ksYX4Hl6A0e" password=password
----ENVIRONMENT-----------------
Runtime: Sun Microsystems Inc. Java HotSpot(TM) Client VM
1.6.0_03-b05
----ARGUMENTS-------------------
input:
k1AwOd5XuW4VfPQtEXEdVlMnaNn19hivMbn1G4JQgq/jArjtKqryXksYX4Hl
6A0e
password: password
----OUTPUT----------------------
This is my message to be encrypted
Configure the Web Services Author Application

The following table lists the files that you must configure for the Web Services Author
application.
wsauthtool/log4j.properties log4j.appender.LOGFILE.File Path to location of

log file
wsauthtool/pmBootstrapConfigs.xml dataSource and daoFactory Change the setting

to match your
database type and
parameters.

Configure the log4j.properties File
Note: You can choose to customize the log4j.properties file or retain the default
settings in the file.
To configure the log4j.properties file:

1. From the WEB-INF/classes directory on the application server, open the
log4j.properties file in a text editor.
2. Change the names of the log files and the paths to the log files, as in the following
example:
# File paths must be changed to full system paths
log4j.appender.LOGFILE.File=C:/BOTLogs/<Back Office
application name>.log
log4j.appender.auditor.File=C:/BOTLogs/<Back Office
application name>.audit.log
3. Change or add to all relevant log files the following value in the DatePattern
parameter, as shown:
log4j.appender.forensic.DatePattern='.'yyyy-MM-dd
4. Change the log files to have the appropriate settings for their rolling appender. For
example, the forensic log file should be changed from
log4j.appender.forensic=com.rsa.csd.utils.log.ForceableSi
zeBasedRollingAppender
to
log4j.appender.forensic=com.rsa.csd.utils.log.ForceableTi
meBasedRollingAppender
5. Change the MaxFileSize parameter.
For the forensics and audit logs, the MaxFileSize parameter is dependent on the
number of transactions that is expected to be handled daily by the Adaptive
Authentication system.
For each transaction, you can assume the following approximate amount of data is
added to each of the logs.
The forensic log receives ~6KB of data per transaction.
The audit log receives ~2KB of data per transaction.
You can use the following setting to limit the size of the files to a maximum of
200MB per file:
log4j.appender.forensic.MaxFileSize=200000KB
This will then roll according to the index that, by default, has the value of 4.
6. Add the following line to the log4j.properties file to enable restore after backup:
log4j.additivity.failedChallenge = false
7. Save the log4j.properties file.

Shared Configuration Information in a Distributed Environment

The Scheduler uses the Adaptive Authentication configuration through the
configuration framework.
If you have installed the Scheduler on a different machine than the Adaptive
Authentication machine, the configuration should be either distributed using a shared
file system or copied to the corresponding machine where the Scheduler is installed.

8 Install and Configure Maintenance Utilities

Batch Loader Utility
Configuring the Batch Loader Utility
Install the ConfigTool Utility
Configure the ConfigTool Utility
eFraudNetwork Agent
Configure eFraudNetwork Files
Encryption Utility
Switch to the New RSA Risk Engine Model
Roll Back to the Previous Risk Engine Model
Install the ws_auth_tool Utility
Configuration Migration Tool
This chapter describes how to install and configure the maintenance utilities after
performing an installation or upgrade.
Batch Loader Utility

The Batch Loader utility is a command-line tool for loading historical customer data
into the RSA Adaptive Authentication (On-Premise) database.
The following personnel are the typical users of the Batch Loader utility:
Customer Application Administrator. This administrator is required to gather
the historical data and may help with formatting the data into the format required
by the Batch Loader utility.
Adaptive Authentication Installer or Administrator. This administrator is
responsible for installing and configuring the Adaptive Authentication system.
Batch Loader Utility Administrator. This administrator is responsible for using
the Batch Loader utility to load historical data. The administrator can be the same
as the Adaptive Authentication Administrator.
The Batch Loader utility user must understand Adaptive Authentication (On-Premise)
and how it works, and must be familiar with the scripting language used.
You can execute the Batch Loader utility in one of the following modes:
Risk Engine only mode. The Batch Loader utility loads data for the Risk
Engine only, but does not create users and devices.
FULL mode. The Batch Loader utility loads Risk Engine data, User IDs, and
devices.
8: Install and Configure Maintenance Utilities 133

The Offline task is a Scheduler task and is enabled by default. If you want to use the
Batch Loader utility, you must disable the execution of the Offline task until the batch
loading is completed.
Install the Batch Loader Utility

Before You Begin
Before installing and running the Batch Loader utility, make sure that the following
tasks are completed:
The RSA Adaptive Authentication (On-Premise) 7.1 database is installed and
configured.
The RSA Adaptive Authentication (On-Premise) 7.1 Scheduler application is
installed.
The geoip_MAXMIND_version number.dat is installed. Keep a record of the
location for reference. You can find the geo_maxmind.dat file in the build
artifacts of the latest release under service.
Batch data loading is completed before the Offline tasks are run.
The proper .jar file for the JDBC driver is installed.
The Batch Loader utility can be installed either before or after the Adaptive
Authentication (On-Premise) application is installed.
To install the Batch Loader utility:

1. Unzip the aa-batch-data-analyzer-package.zip file.
The following directories are created:
collect. Location in which the input files are placed.
processed. Location in which the processed files are moved.
logs. Location in which all log files are stored.
configs. A series of configuration files
lib. Compiled .jar files.
The following files are included in the .zip file
pmBootstrapConfigs.xml. The system configuration file that contains
the DAO objects and is used to bootstrap the configurations.
rsaCollectionAnalysis.bat. The command file used to start the batch
loading process for customers using Windows.
rsaCollectionAnalysis.sh. The command file used to start the batch
loading process for customers using UNIX.
2. Edit the config.properties file to configure the following parameters according to
your database vendor:
db.vendor
geolocation.home
134 8: Install and Configure Maintenance Utilities

3. Edit the pmBootstrapConfigs.xml file to specify the database settings

appropriate to your database vendor.
4. Set the JDBC driver for your database in the following files, according to your
operating environment.
For Windows:
rsaCollectionAnalysis.bat
generateFraudMarkingData.bat
For Unix:
rsaCollectionAnalysis.sh
generateFraudMarkingData.sh
Configuring the Batch Loader Utility

The Batch Loader utility runs in its own JVM and loads its own configurations. The
provided .bat file and .sh files contain the command lines needed to run the Batch
Loader utility.
Before running the Batch Loader utility, there are configuration files that need to be
revised. The following is a list of the files that need setup configurations and the data
items contained in each configuration file that require revisions.
pmBootstrapConfigs.xml
database location
database user name
database password
JDBC driver
rsaCollectionAnalysis.bat (Windows) or rsaCollectionAnalysis.sh (UNIX)
libpath
JDBC driver
config.properties
db.vendor: Uncomment the lines that are relevant to your database
environment (Oracle or MS SQL).
db.creVendor: Uncomment the lines that are relevant to your database
environment (Oracle or MS SQL).
db.schemaName: Specify the database schema name.
generateFraudMarkingData.bat (Windows) or
generateFraudMarkingData.sh (UNIX) - Set the JDBC driver for the destined
database (available from the database installation) and copy it to the lib directory
of the loader installation.

c-config-aa-batch-data-analyzer.xml
In the common.rsaaa.callerid field, enter the name of the Adaptive
Authentication Admin user.
In the common.rsaaa.callercredential field, enter the password for the
Adaptive Authentication Admin user.
Configure the Batch Loader Utility to Run in Risk Engine Mode

RSA recommends running the Batch Loader utility in the Risk Engine mode because
it runs faster and performs better than in the Full mode and only loads the Risk Engine
data tables.
The following configuration files are created during the installation and are needed for
loading data:
c-config-aa-batch-data-field-mapping.xml
c-config-aa-batch-data-value-mapping.xml
c-config-cre-batch-data-field-mapping.xml
c-config-cre-batch-data-value-mapping.xml
To configure the Batch Loader Utility to run in Risk Engine Mode:

1. Open the c-config-aa-batch-data-analyzer.xml file.
2. Locate the collect.analysis.loader_type key.
3. Set the value to ENGINE_ONLY.
Configure the Batch Loader Utility to Run in Full Mode

Full mode sends data through the Risk Engine and creates entries in the User and
Desktop (device) tables in Adaptive Authentication. Full mode must only be used
when device recognition and recovery play a key role in authentication.
Even when Full mode is used, it is recommended to send only a small amount of the
data through Full mode, to reduce processing time lines.
The following configuration files are created during the installation and are needed for
loading data:
c-config-aa-batch-data-field-mapping.xml
c-config-aa-batch-data-value-mapping.xml
c-config-cre-batch-data-field-mapping.xml
c-config-cre-batch-data-value-mapping.xml

To configure the Batch Loader Utility to run in Full Mode:

1. Open the c-config-aa-batch-data-analyzer.xml file.
2. Locate the collect.analysis.loader_type key.
3. Set the value to ALL.
Fact Files
In the c-config-cre-batch-data-field-mapping.xml configuration file, there is a new
fact that you should use to send the device ID to the batch loader. The device ID is
obtained from the cookie.
You should add the following line in the batch loader input files to use the new fact:
deviceSourceCookieId=cookieID
Install the ConfigTool Utility

As of version 6.0.2.1 SP2, the installation module installs the ConfigTool. RSA
provides a file, configTool.zip, that contains the necessary files for you to run this
tool. Use this tool to change your installation configuration.
To change your installation configuration:

1. Copy the configTool.zip file from your distribution package to a directory and
unzip it into a manually created directory, for example, ConfigTool. After you
unzip it, the new directory includes the following:
/lib directory
log4j.properties
pmBootstrapConfigs.xml
l_RunConfigTool.sh (UNIX)
w_RunConfigTool.bat (Windows)
2. Copy the JDBC driver files of your database vendor to the ConfigTool directory.
You must add the following JDBC drivers to the lib directory to connect to the
Core Database:
Microsoft SQL Server 2005: sqljdbc.jar
Microsoft SQL Server 2008: sqljdbc4.jar
3. Open the pmBootstrapConfigs.xml file in a text editor and modify the
information so that it is specific to the database that you are using. By default, the
Oracle database is configured. If you are not using Oracle, you must modify the
entries.

For example, to use the MS SQL entries, delete the XML comments around that
entry, and add comments around the unused entries.




<value>com.microsoft.jdbc.sqlserver.SQLServerDriver</valu
e>
</property>
<value>jdbc:microsoft:sqlserver://<ipaddress>:<port>;data
base=<dbname></value>
</property>
<value><db user name></value>
</property>
=


4. Add the following for the database entry that you are using:
The IP address (or host name)
Port number
Database name information for the URL value
5. Enter an appropriate user name value for the database entry. The database user
account must have the appropriate administrative level permissions for your
database.
The tool also requires a password for the database user account. The password is
entered on the command line when you run the tool.
6. Modify the DAO information so that it is specific to the database that you are
using. By default, the XML file is configured to use an Oracle database. If you are
not using Oracle, you must modify the entries. For example, to use the MS SQL
entries, delete the XML comments around that entry, and add comments around
the unused entries.




7. Save the file.
8. Make any modifications to the tool, depending on the action you want to take. For
more information, see:
Add a Configuration Tree to the Database on page 140.
Export the Configuration Space Tree to a File on page 142.

Configure the ConfigTool Utility

The following table lists the files that you must configure for the ConfigTool utility.
Path and Filename Variable Value
configtool/log4j.properties log4j.appender.LOGFILE.File Path to location of

log file
configtool/pmBootstrapConfigs.xml configTreeName Label for

configurations to put
into database
Should match the
label in the
AdaptiveAuthenticat
ion web.xml file
configTreePath Path of
configuration folder
to upload
outputPath Path of
configuration folder
to download
driverClassName JDBC driver name

to upload to
database
url JDBC URL to

database
username JDBC user for

database
Add a Configuration Tree to the Database

Prior to loading the configurations, you need to set up the necessary files and create a
directory hierarchy that mimics your Configuration Tree. For more information, see
the Operations Guide.
The RSA Risk Engine configuration is not uploaded to the database. It is necessary to
copy an identical Risk Engine configuration to all application servers.
To add a Configuration Tree to the database:

1. Open the pmBootStrapConfigs.xml file.
2. Make any appropriate changes to this file, including providing the right
parameters for the bean, boostrapConfigs, datasource settings, and DAO layer
settings.

3. Provide the following parameters in the file:

action. Save
configTreePath. The local path where the Configuration Tree and Spring files
reside.
configTreeName. The name that you want for the Configuration Tree. This
name is what you need to reference for the server to load the configurations
and to switch, update, or delete the contents.
<bean id="bootstrapConfigs"
class="com.passmarksecurity.config.admin.BootstrapConfigs
">
<property name="action">
<value>save</value>
</property>
<property name="configTreeName">
<value>PMDefaultConfigs</value>
</property>
<property name="configTreePath">
<value>C:\configurationDir</value>
</property>
</bean>
4. Run either the w_RunConfigTool.bat (Windows) or the I_RunConfigTool.sh

(UNIX) file. The configurations are loaded into the database.
5. Enter your database password when prompted. If the Configuration Tree already
exists, you are prompted to confirm the overwrite.
6. Edit your web.xml file to point to the correct Configuration Tree.
After you load the configurations into the database, you need to set up each of your
servers to point to it.
Note: You can use this function to save changes to your existing Configuration Tree in
the database. However, this function overwrites the entire Configuration Tree.
Important: This function deletes an existing Configuration Tree from the database. If
a Configuration Tree is deleted, it is the responsibility of each application server to
pick up the new changes, either directly or through the use of a JMX. Before deleting
a Configuration Tree, make sure that no PassMark instance is using it.

To set up the servers:

1. In the pmBootstrapConfigs.xml file, set the values for the following parameters
as noted:
action. Delete
configTreePath. A local path where the files are saved
configTreeName. The name of the Configuration Tree to be deleted.
class="com.passmarksecurity.config.admin.BootstrapConf
igs">
<value>delete</value>
</property>
<value>PMDefaultConfigs</value>
</property>
</bean>
2. Call the ConfigToolCOnsole file that deletes the specified Configuration Tree.
Export the Configuration Space Tree to a File

You can convert a Configuration Tree to .xml files that are exported to a prescribed
directory location. For each Configuration Tree, a mapped directory hierarchy of
Configuration Spaces is created. Each Configuration Definition defined in a
Configuration Space is represented as a bean definition in a single file.
This action creates multiple files that contain all of the configurations that are based
on the original configuration files.
To export the configuration space tree to an xml file:

1. Set the pmBootstrapConfigs.xml file with the following variables:
action. tofile.
configTreePath. Local path where the files are saved.
configTreeName. Name of the Configuration Tree in the database that you
want to export to the file. If this parameter is not specified, a file
representation of all the stored Configuration Tree is provided instead.
Groups. Specifies if you want groups from the Configuration Tree to be
written to a file. If this parameter is empty, no groups are exported to a file.
The default value is ALL.
Resources. Specifies which resources in the Configuration Tree that you want
written to the file. If empty, no resources are exported to a file. The default
value is ALL.

advancedGroups. Denotes the files are to have Spring 2.5 header. You must
not change the values of this property.
class="com.passmarksecurity.config.admin.BootstrapConfigs
">

<value>tofile</value>
</property>


<value>PMRoot</value>
</property>

<property name="configTreePath">
<value>c:\PassMark\Configs</value>
</property>

<property name="outputPath">
<value>C:\temp</value>
</property>

<property name="groups">
<list>
<value>all</value>
</list>
</property>

groups are spring 2.5. Please do not change the values in
the list-->
<property name="advancedGroups">

<list>
<value>d-config-configService</value>
<value>d-config-reporting</value>
</list>
</property>

resources are to be included-->
<property name="resources">
<list>
<value>all</value>
</list>
</property>
</bean>
2. Run one of the following files according to your operating environment:

For Windows: w_RunConfigTool.bat
For Unix: I_RunConfigTool.sh
The configurations are exported to a file.
eFraudNetwork Agent
The eFraudNetwork is a collaboration of organizations that share information on
fraudulent activity. This information is used as a factor in the risk analysis of a given
transaction.
You can install the eFraudNetwork agent in the following ways:
As a scheduled task (recommended). In this case, the Scheduler configures the
eFraudNetwork agent. For more information, see the Operations Guide.
As a standalone component. In this case, you must manually configure the agent
in the efnagent-context.xml file because the Scheduler does not have access to
the Internet or DMZ for security reasons. If you want to install the eFraudNetwork
agent as a standalone component, you must install one agent in the DMZ and
another agent in the internal network.
You need to manually transfer the new eFraudNetwork file from the agent in the
DMZ to the agent in the internal server. The agent in the internal server loads the
new eFraudNetwork file to the Adaptive Authentication system.
For more information on configuring the eFraudNetwork files, see Configure
eFraudNetwork Files on page 145.

Configure eFraudNetwork Files

You can configure the eFraudNetwork agent parameters using the Administration
Console. The following table lists the files that you must configure for the
eFraudNetwork agent application.
efnagent/agentcmd.bat, efnagent/agentcmd.sh
efnagent/bin/log4j.properties log4j.appender.LOGFILE.File Path to location of

log file
efnagent/bin/pmBootstrapConfigs.xml daoConfig Uncomment the

database type that
you intend to use
and set the URL,
user name, and
password for
database.
Comment out or
remove the
database types
that you do not
intend to use.
efnagent/bin/efnagent-context.xml
Configure the efnagent-context.xml File

Depending on your companys security considerations, you might need to install the
eFraudNetwork agent in your networks DMZ. If the eFraudNetwork agent is installed
in the DMZ, you need to configure the parameters in the efnagent-context.xml.
The following table lists the parameters in the efnagent-context.xml file and their
descriptions:
Parameter Description Required
caller_id The user name of the eFraudNetwork account Yes
caller_password The password for the eFraudNetwork account. Yes
efnServer The name or IP address for the efn server. Yes
proxyEnabled Indicates whether or not the eFraudNetwork Yes

agent must use a proxy server to reach the
eFraudNetwork server. The default value is
false.
proxyHost The name of the proxy server. No

If you enabled the proxy, this field is required.

Parameter Description Required
proxyPort The port through which the traffic to the proxy No

must travel.
proxyUser The user name for the proxy account. No

proxyPassword The password for the proxy account. No

lastLocalVersion Indicates the version of the local file for the Yes
following entities:
IP
Device
Payee
If the local file version is lower than the
version available on the eFraudNetwork
server, the eFraudNetwork agent updates the
file for the respective entity.
Test the Connectivity

Credentials required to access the eFraudNetwork agent are unique to each customer
and are provided separately by RSA.
Before You Begin

Set Up a Trusted Certificate
To test the connectivity:

1. Start the eFraudNetwork agent.
2. If you have successfully received the file from the eFraudNetwork, the connection
was successful.
If you did not receive the file, check the log file for the error details.

Checking for Updates

Regardless of whether or not you are using the eFraudNetwork agent through manual
or automatic updates, you can determine connectivity and ensure that you receive
information.
Check for Manual Updates
To check if the eFraudNetwork Agent successfully pulled a file from the

eFraudNetwork:
1. Access the file from the location you specified in the eFraudNetwork agent script.
2. Search for the string METADATA, <entityType>, where entityType can be
ip
payee
device
3. Identify the letter following the string for which you searched.
S. Indicates the file or database was successfully updated with new
information from the eFraudNetwork. A value should display in the column
number of pulled rows.
F. Indicates an attempt to update the file or database failed. No information
was updated. In the eFraudNetwork file, if the value is F, then the rest of the
file is empty.
N. Indicates that the eFraudNetwork agent was successful in pulling
information from the eFraudNetwork but no new information was updated.
Check for Automatic Updates
To check the database to determine if information was pulled successfully:

1. Access the Core Database.
2. Locate the database table EFN_LOCAL_METADATA. The table contains
several rows that include the following values for the file and database.
LOCAL_UPDATE_DATE. The last time the file (manual) or table
(database) was updated.
UPDATE_STATUS. Indicates whether the information is updated
successfully, the update failed, or if no changes were made, as follows:
S. The file or database was successfully updated with new information
from the eFraudNetwork. A value should display in the column number
of pulled rows.
F. An attempt to update the file or database failed. No information was
updated. In the eFraudNetwork file, if the value is F, then the rest of the
file is empty.
N. The eFraudNetwork agent was successful in pulling information from
the eFraudNetwork but no new information was updated.

PUSHED_ROWS_NUMBER. The number of rows of information that are

pushed to the eFraudNetwork. This number should always be zero (0).
PULLED_ROWS_NUMBER. The number of rows of information in the file
or pulled to the database. This row indicates how much information is updated
from the eFraudNetwork.
LOCAL_VERSION. The version of the eFraudNetwork data for the given
data type.
DATA_TYPE. The type of data for which the information applies. Possible
values are:
ip
payee
device
Encryption Utility
The Adaptive Authentication (On-Premise) system stores the list of seeds, questions,
answers, and phrases that can be encrypted. The system also stores customized fields
that are part of user-implemented Authentication Plug-ins that can also be encrypted.
You can use the Encryption utility to manage all administrator activities related to key
management and to perform the following tasks:
Generating a new master key. If the encryption feature is enabled, you must
generate a master key seed.
Rotating the master key. If the encryption feature is enabled and you want to
change the master key for security considerations, use this utility to rotate the
master key.
Dumping the plain seeds to file. Extracts all plain key seeds values and writes
them to a file. This is required if you lose the master key.
Loading plain seed from backup. This is required if you lose the master key and
you want to recover the key from backup.
For more information about the Encryption utility, refer to the section about
encrypting user data in the Operations Guide.
Switch to the New RSA Risk Engine Model

The Risk Engine model is upgraded when you upgrade from RSA Adaptive
Authentication (On-Premise) 6.0.2.1 to RSA Adaptive Authentication (On-Premise)
7.1. If you are upgrading from RSA Adaptive Authentication (On-Premise) 7.0 (in
which the new model was introduced), it is assumed that you switched to the new
model when you upgraded from 6.0.2.1 to 7.0.
After you upgrade to RSA Adaptive Authentication (On-Premise) 7.1, the Risk
Engine model runs in silent mode until you run a script to switch to the new model.
The recommended time to switch to the new model is 45 days.

To switch to the new model:

1. Navigate to the rootdirectory\utils_7.1\risk_model_manager directory.
2. Run the following script:
On UNIX:
./l_RunRiskModelManagerTool.sh -U
Note: Run the script on UNIX as root or any other user who has the required
permissions.
On Windows:
w_RunRiskModelManagerTool.bat -U
Note: You are prompted for the application user password when you run the
script. If the JAVA_HOME variable is not set up, you are prompted to set it up.
Roll Back to the Previous Risk Engine Model

To roll back to the previous model:
1. Navigate to the rootdirectory\utils_6.0.3.0.0\risk_model_manager directory.
2. Run the following script:
On UNIX:
./l_RunRiskModelManagerTool.sh -R
On Windows:
w_RunRiskModelManagerTool.bat -R
Install the ws_auth_tool Utility

To install the ws_auth_tool utility:
1. In the pmBootstrapConfigs.xml file, set the database vendor by uncommenting
the relevant daoConfig bean:
For Oracle, uncomment the following:
class="com.passmarksecurity.dao.config.DAOConfigOracle"
/>
For MSSQL, uncomment the following:
class="com.passmarksecurity.dao.config.DAOConfigMSSQL"/>

2. In the pmBootstrapConfigs.xml file, set the database connection settings

depending on your database vendor as shown:
<value>value_of_property</value>
</property>
</property>
</property>
3. In the log4j.properties file, configure the location of the log file as shown:
log4j.appender.LOGFILE.File=wsauthtool.log
4. Copy the database driver library for your database vendor to the lib directory.
5. Configure the database driver library, as shown:
For UNIX (l_RunWSAuthTool.sh):
JDBC_DRIVER=path_to_database_library
For Windows (w_RunWSAuthTool.bat):
set JDBC_DRIVER=path_to_database_library
Configuration Migration Tool

The Configuration Migration tool is used by the upgrade module to migrate all the
configuration changes made in RSA Adaptive Authentication (On-Premise)
6.0.2.1 SP2 to the Administration Console in RSA Adaptive Authentication
(On-Premise) 7.1. You can select the Configuration Migration option on the
Upgrade Components screen of the upgrade module to run the tool automatically.
This topic describes how you can manually run the Configuration Migration tool if
you did not select the Configuration Migration option in the upgrade module.
You can find this tool in the utils_7.1.0.0.0\configuration-upgrade directory. The
Configuration Migration tool searches through the Adaptive Authentication
(On-Premise) 6.0.2.1 SP2 configuration files, locates all the relevant parameters that
are changed from their original values, and saves the changes in the export file. You
can load this export file into the database using the Export button in the
You can use the following command to manually run the Configuration Migration
tool:
On Windows, type:
configurationUpgradeManager.bat [-P password]
On UNIX, type:
configurationUpgradeManager.sh [-P password]
The password parameter is optional.

Configure the Configuration Migration Tool

To configure the Configuration Migration tool:
1. In the pmBootstrapConfigs.xml file, configure the dataSource bean by setting
the values of driverClassName, url, and username properties, according to the
Core Database definitions.
2. Configure the following properties in the configuration-upgrade-context.xml
file:
exportFileLocation. Defines where the export file will be saved. You can set
this property to point to the current location.
originalAAConfigLocation. Represents the location of the original
configuration files for the version from which you are upgrading, with which
the upgrade tool is packaged.
modifiedAAConfigLocation. Represents the location of the modified
configuration files for the version from which you are upgrading. You must
set this property to point to the original back-up location of the configuration
files and not where the files for the Adaptive Authentication (On-Premise) 7.1
upgrade module are located.
originalSchedulerConfigLocation. Represents the location of the original
Scheduler configuration, with which the Configuration Migration tool is
packaged, for the version from which you are upgrading.
modifiedSchedulerConfigLocation. Represents the location of the modified
Scheduler configuration.
originalBOConfigLocation. Represents the location of the original files,
such as aa-backoffice-config.xml, casemanagement-config.xml,
config.properties, and database.properties for the version from which you
are upgrading with which the Configuration Migration tool is packaged.
modifiedBOConfigLocation. Represents the location of the modified files,
such as aa-backoffice-config.xml, casemanagement-config.xml,
config.properties, and database.properties. If this directory does not exist,
you must create it and copy the files to this directory. For more information,
see Upgrade Prerequisites on page 65.
3. Configure the following in the configurationUpgradeManager.bat or
configurationUpgradeManager.sh file:
Ensure that LIBDIR points to the library directory containing all the libraries
within the Configuration Upgrade tool.
Ensure that the JDBC_DRIVER points to the JDBC driver library.
Ensure that the classpath -cp property is extended to contain the path to both
the original 6.0.2.1 SP2 scheduler configuration and the modified 6.0.2.1 SP2
scheduler configuration locations described in the preceding section.
Log Files
The log files for the Configuration Migration tool are available in the
utils_7.1\configuration-upgrade-7.1\logs directory.

9 Install and Configure Development Utilities

Install rsa-auth-plugin-tools
Install Updated Web Resources Files
This chapter describes how to install and configure the development utilities after
performing an installation or upgrade.
Install rsa-auth-plugin-tools
To install the rsa-auth-plugin-tools.zip utility:
1. In the config.properties file, set the database vendor as shown:
db.vendor=Oracle/MSSQL
2. In the pmBootstrapConfigs.xml file, set the database connection settings as
shown:
</property>
</property>
</property>
<property name="password">
</property>
3. In the acsp-tools-context, set the output file directory as shown:
<property name="outputFileDir">
</property>
4. In the log4j.properties file, configure the location of the log file, as shown:
log4j.appender.LOGFILE.File=logs/acspTools.log
log4j.appender.alarm.File=logs/acspTools.alarm.log
5. Copy the database driver library for your database vendor to the lib directory.
9: Install and Configure Development Utilities 153

6. Configure the database driver library, as shown:

For UNIX (userDataQuery.sh):
JDBC_DRIVER=path_to_driver_library
For Windows (userDataQuery.bat):
set JDBC_DRIVER=path_to_driver_library
Install Updated Web Resources Files

This section describes how to use the updated Web Resources files that are included in
the WebResources.zip package, located in the dev_utils_7.1.0.0.0 folder.You must
replace the following updated Web Resources files:
rsa.js
pmfso.swf
To install rsa.js:
1. In the online site code, back up the existing rsa.js JavaScript file.
Note: When you back up the file, do not rename it, for example, pm_fp-old.js or
pm_fp.old. Remove the file completely from the directory.
2. Copy the rsa.js file from the WebResources.zip folder and paste it into the online
site directory.
To install pmfso.swf:
1. In the online site code, back up the existing pmfso.swf file.
Note: When you back up the file, do not rename it, for example, pm_fp-old.js or
pm_fp.old. Remove the file completely from the directory.
2. Copy the pmfso.swf file from the WebResources.zip folder and paste it into the
online site directory.
154 9: Install and Configure Development Utilities

Prevent Caching of the Flash File by the Flash Player

Refer to the following updated Web Resources reference files to prevent caching of
the Flash file by the Flash player on your browser:
pmfso.jsp. Shows how to run the Flash movie and retrieve the device token
from the FSO.
pmfso_set.jsp. Shows how to run the Flash movie and set the device token in
the FSO.
To prevent caching of the Flash file by the Flash player on your browser:
Send an additional parameter with a volatile value, such as a timestamp, to the Flash
file. For example, see the nocache parameter in the following code.
var d=new Date().getTime();
var out = "";
out = out + "<object
classid='clsid:D27CDB6E-AE6D-11cf-96B8-444553540000'" +"\n";
out = out + "width='500' height='500'>" + "\n";
out = out + "<param name='movie' value='pmfso.swf?nocache="
+ d + "'>" + "\n";
out = out + "<param name='quality' value='high'>" + "\n";
out = out + "<param name='bgcolor' value=#FFFFFF>" + "\n";
out = out + "<param name='FlashVars'
value='gotoUrl=<%=gotoUrlEnc%>&sendUrl=<%=sendUrlEnc
%>&browserType=" +BrowserDetect.browser + "'>" +
"\n";
out = out + "<embed src='pmfso.swf?nocache=" + d + "'" +"\n";
out = out + "FlashVars='gotoUrl=<%=gotoUrlEnc%>&sendUrl=<%=
sendUrlEnc%>&browserType="
+BrowserDetect.browser+"'"+ "\n";
out = out + "quality='high' bgcolor='#FFFFFF' width='1'
height='1' " + "\n";
out = out + "type='application/x-shockwave-flash'>" + "\n";
out = out + "<noembed>" + "\n";
out = out + "<script>" + "\n";
out = out + "navigateToUrl('<%=gotoUrl%>');" + "\n";
out = out + "</script>" + "\n";
out = out + "</noembed>" + "\n";
out = out + "<noobject></noobject>" + "\n";
out = out + "</embed>" + "\n";
out = out + "<noobject></noobject>" + "\n";
out = out + "</object>" + "\n";
document.write(out);
9: Install and Configure Development Utilities 155

A Set Up the Application Servers

Setting Up WebSphere with Oracle
Setting Up the BEA WebLogic Application Server
This appendix describes how to set up the IBM WebSphere application server. It also
describes how to set up a trusted certificate for WebSphere application servers.

To allow the RSA eFraudNetwork agent to make an HTTPs request to the
eFraudNetwork service at RSA, you must download and install the trusted certificate.
Download the Trusted Certificate

On a UNIX or Linux machine, you can use OpenSSL to download the trusted
certificate. On a Windows machine, you must use a browser to download and save the
trusted certificate.
Before You Begin

To use OpenSSL:
Your firewall must be open to connect to the eFraudNetwork server.
You must use a UNIX or Linux machine.
To download the trusted certificate:

Do one of the following:
On Unix or Linux, using OpenSSL, download the root CA certificate from the
eFraudNetwork website, type:
openssl s_client -connect secureft.efraudnetwork.net:443
-showcerts < /dev/null 2> /dev/null | \sed -ne
'/s\:\/O\=RSA\ Security\ Inc\/OU\=RSA\ Security\ 2048\
V3/,/END\ CERTIFICATE/ p' > rsa-security-2048-v3.pem
On Windows, follow these steps:
a. If you are using Microsoft Internet Explorer, add
https://secureft.efraudnetwork.net to the trusted sites list.
a. Open a new browser instance, and go to
https://secureft.efraudnetwork.net/eFraudNetwork/eFraudNetwork.
b. Click on the padlock icon, and view the certificates.
c. Download and save the root CA certificate.
A: Set Up the Application Servers 157

Import the Trusted Certificate to the Java Truststore

Before You Begin
The JAVA_HOME variable must be set correctly.
To import the trusted certificate:

1. Copy the saved certificate file to the JAVA_HOME/jre/lib/security directory on
the server where your application server is running.
2. Open a command prompt and change directories to
JAVA_HOME/jre/lib/security.
3. To import the certificate to the Java truststore, enter the appropriate command for
the platform.
On Windows, type:
%JAVA_HOME%/bin/keytool -import -alias "RSA Security 2048
v3" -file cert_filename -keystore
%JAVA_HOME%/jre/lib/security/cacerts -storepass password
On UNIX or Linux, type:
$JAVA_HOME/bin/keytool -import -alias "RSA Security 2048
v3" -file cert_filename -keystore
$JAVA_HOME/jre/lib/security/cacerts -storepass password
where:
cert_filename is the name of the certificate file that you saved.
password is the password of the Java truststore, cacerts. The default password
of cacerts is changeit.
Setting Up WebSphere with Oracle

This section provides information on how to set up WebSphere using an Oracle
database. Before you can properly set up WebSphere using an Oracle database, you
need to set up and install the database.
Important: Sensitive data, such as database passwords, is stored in the WebSphere

configuration files. Make sure that you use a password encryption mechanism that
allows proper encryption of passwords saved in the configuration files.
In the WebSphere application server, connections are shared by default. The use of
shareable connections implies that different connection requests by the application,
made within the same business transaction, actually receive a handle for the same
physical connection to the resource. The benefit of this is a reduction in the number of
physical connections that need to be managed.
When the application closes a shareable connection, the connection is not truly closed,
nor is it returned to the free pool. Rather, it remains in the Shared connection pool,
ready for another request within the default transaction context for a connection to the
same resource.
158 A: Set Up the Application Servers

RSA recommends that you set the connection pool sharing parameter to "unshared".
If you must use shared connections, ensure that you set the maximum size of the
connection pool to be greater than the maximum number of threads plus the number of
concurrent Scheduler tasks plus one for the session reaper.
Connection Pool Configurations

RSA recommends default values for WebSphere application server connection pool
configuration parameters.
Procedure
Set connection pool configurations as per the following recommended values:
Connection timeout = 60 sec
Reap time = 30 sec
Unused timeout = 30 sec
Aged timeout = 0 (remains in the pool indefinitely)
JDBC Data Source for Oracle

To set up WebSphere using Oracle, you need to create a JDBC data source for Oracle.
Procedure
1. Create a J2C authentication alias.
2. Create the data source.
3. Test the database connection.
Create a J2C Authentication Alias

Before You Begin
Ensure that the datasource is set to use component-managed authentication.
To create a J2C authentication alias:

1. Select the alias name from the JAAS - J2C authentication data menu. If you do
not have an alias name available, click create a new J2C authentication alias,
and perform the following steps:
a. Click New.
b. On the Configuration page, in the General Properties area, enter values for
the following parameters:
Alias. An alias for the User ID. This alias is used when setting the JDBC
configuration.
User ID. User ID that was created in the database.
Password. Password for the user ID.

Description. Descriptive text for the alias.
c. Click OK.
d. Click Finish to save the changes to the master configuration.
Create a JDBC Data Source for Oracle

To create a JDBC data source for Oracle:
1. Log on to the application server.
2. Define general data source parameters.
3. Create a JDBC provider.
4. Define database-specific properties.
5. Setup the security aliases.
Log On to the Application Server

2. Click Resources > JDBC > Data sources.
3. Expand Scope, and select the server-level scope from the menu.
4. Under Preferences, click New.
Define General Data Source Parameters

1. On the Create a data source page, do the following:
a. Enter your Data source name, for example, RSADBOracle.
b. In the JNDI name field, type:
jdbc/PassMarkDB
2. Click Next.
Create a JDBC Provider

1. On the Select JDBC provider page, select Create new JDBC provider.
2. Click Next.

3. On the Create a new JDBC provider page, select the following from the
drop-down menus:
Database type: Oracle
Provider type: Oracle JDBC Driver.
Implementation type: Connection pool data source
In the Name field, enter a name for the JDBC provider, for example,
RSADatabase, or use the default.
4. Click Next.
5. On the Enter database class path information page, in the Class path field, enter
the absolute path to the directory location for the JDBC driver file ojdbc14.jar,
for example, C:\releases\PMDB.oracle.
If you do not change the absolute path to the driver files, the following error
message appears:
The classpath attribute contains a variable that begins with
a dollar sign ($). Verify that this variable is defined, by

clicking Environment > WebSphere Variables, for each

physical machine that the Java Database Connectivity (JDBC)
provider is used on.
Important: You must use a JDBC driver that is appropriate for your database
server and compatible with JVM 1.6. An incompatible driver can reduce the
performance of the system.
6. Click Next.
Define Database-specific Properties

1. On the Enter database-specific properties for the data source page, enter the
following information:
a. In the URL field, enter the JDBC connection string for the database that
contains the IP address, port number, and database name, for example,
jdbc:oracle:thin:@IP address:port number:database name
b. From the Data store helper class name list, select the appropriate name and
database version.
2. Click Next.
Setup Security Aliases

1. On the Setup Security Aliases page, select the following from the drop-down
menus and click Next:
Component-managed authentication alias: The J2C alias you created
Create a J2C Authentication Alias on page 159.
Mapping-configuration alias: (none).

Container-managed authentication alias: (none).
2. The Summary page for your configuration is displayed. Verify that the
information is correct and click Finish.
Test the Connection

To test the connection:
On the Data sources page, select the checkbox next to the data source that you
created, and click Test Connection to verify the JDBC configuration.
You should see a Successful message. If you do not see this message, make sure that
your database-properties settings are correct.
Setting Up the BEA WebLogic Application Server

Before You Begin
1. Make sure that the application server is started and running.
2. Launch the WebLogic Administration Console.
3. Log on to the Administration Console.
To set up the JDBC data source on the WebLogic application server:

1. Click Services > JDBC to open the Summary of Services page.
2. Select Data Sources.
3. On the Summary of JDBC Data Sources page, in the Change Center area, click
Lock & Edit.
4. Click New.
5. On the Create a New JDBC Data Source page, enter your data source name.
6. In the JNDI Name field, type:
jdbc/PassMarkDB

7. From the Database Type menu, select the appropriate database type (Oracle, MS
SQL Server).
8. From the Database Driver list, select one of the following:
For MS SQL Server, select
MS SQL Server Driver (Type 4) Version:2005
MS SQL Server Driver (Type 4) Version:2008
For Oracle, select Oracle Driver (Thin) Versions:
Oracle 10g - ojdbc14.jar
Oracle 11g - ojdbc6.jar
You must copy the appropriate JDBC driver files for your database vendor to the
lib directory in WebLogic, for example,
C:\bea\weblogic10_3\samples\domains\wl_server\lib.
Make sure to select the appropriate driver based on the database vendor.
9. Click Next.
10. Under Transaction Options, leave all of the default selections, and click Next.
11. On the Connection Properties page, define the properties for the data source that
you are creating:
a. Enter the Database Name. This is the name of the Core Database.
b. Enter the Host Name of the Core Database.
c. Enter the Port number for the Core Database.
d. Enter the Database User Name. The user must have administrative access to
the database.
e. In the Password and Confirm Password fields, enter the database users
password.
f. Click Next.
12. Under Test Database Connection, review the connection properties that you
have provided, and click Test Configuration.
13. Do one of the following:
If you receive a message that the connection test succeeded, click Next.
If you receive an error message, verify that:
The correct data source options are selected
The database connection properties are correct
The Core Database is up and running.
14. Under Select Targets, select the checkbox for your application server.
15. Click Finish.
The data source that you created is listed on the Summary of JDBC Data
Sources page.

B Support for Real Application Clusters

Changes Required to Support RAC Active/Active Configuration
Implement Risk Engine Offline Tasks on a RAC Configuration
Implement Adaptive Authentication (On-Premise) Online Activity on a RAC
Configuration
Add Adaptive Authentication (On-Premise) RAC Support for a New RAC Node
This appendix describes the changes that should be made to the RSA Adaptive
Authentication (On-Premise) database to work on the Active/Active Real Application
Clusters (RAC) configuration. It also describes how to add Adaptive Authentication
(On-Premise) RAC support for a new RAC node.
Changes Required to Support RAC Active/Active Configuration

Cluster wait events occur when multiple cluster nodes try to access the same set of
data blocks. When the Adaptive Authentication (On-Premise) system is deployed on
an Active/Active RAC configuration, multiple cluster nodes are trying to
simultaneously insert new records to the same set of data blocks or update the newly
inserted records. This leads to GC wait events. To resolve this issue, each node needs
to be configured to access a particular subset of data.
To ensure that the Risk Engine Offline Tasks work properly, these tasks must be
configured to work with a dedicated service, which works on an Active/Passive
configuration. The Offline Task continues to work as it would on an Active/Passive
configuration. For more information, see the following section, Implement Risk
Engine Offline Tasks on a RAC Configuration.
To ensure that the Adaptive Authentication (On-Premise) online activity works
properly, central tables must be partitioned (list partitions). In Oracle, each cluster
node has a unique identifier referred to as the RAC instance ID, which is the same as
the new partition key of the central Adaptive Authentication (On-Premise) tables. This
is denoted by a new column added to the central Adaptive Authentication
(On-Premise) tables, RAC_INSTANCE_ID. The default value of the new column,
and the partition key, is the RAC instance ID defined as
SYS_CONTEXT(''USERENV'',''INSTANCE'').
For more information, see Implement Adaptive Authentication (On-Premise) Online
Activity on a RAC Configuration on page 166.
This solution requires a partitioning license for the Oracle database.
B: Support for Real Application Clusters 165

Implement Risk Engine Offline Tasks on a RAC Configuration

To ensure that Risk Engine Offline Tasks work properly on a RAC configuration:
1. Create a new database service, restricted to be active on a single RAC node at any
given time, as follows:
a. Connect to any of the RAC nodes as a user that belongs to the ORADBA
operating system group, for example, the user oracle.
b. Display a list of the available nodes, as follows:
srvctl status database -d <db.name>
For example, while connected to the database server machine, type:
srvctl status database -d dbrac
c. Create a new service and restrict it to work with a single node
(Active/Passive), as follows:
srvctl add service -d <db.name> -s OFFLINE_SERVICE -r
<instance1.name> -a <instance2.name>
srvctl add service -d dbrac -s OFFLINE_SERVICE -r
dbrac1 -a dbrac2
d. Start the new OFFLINE_SERVICE service, as follows:
srvctl start service -d <db.name> -s OFFLINE_SERVICE
srvctl start service -d dbrac -s OFFLINE_SERVICE
2. Configure the Offline Task to work with the new service in Active/Passive mode.
Implement Adaptive Authentication (On-Premise) Online Activity

on a RAC Configuration
To add Adaptive Authentication (On-Premise) RAC support:
1. While connected as an administrative user, for example, SYSTEM, grant the
privilege to create tables to the Adaptive Authentication Core schema.
This is required because the new tables and the partitioned tables are created by a
stored procedure. An explicit grant must be granted.
For example, while connected to sqlplus as an administrative user, type:
SQL> GRANT CREATE TABLE TO <core_schema>;
2. Connect as the <core_schema> user.
3. Create the RSA_RAC package in the Adaptive Authentication Core schema.
To create the necessary tables and the package, run the 01_Install_Packages.sql
script, which is located in the utils_7.1.0.0.0/RAC folder.
For example, while connected to sqlplus, type:
SQL> @01_Install_Packages.sql
166 B: Support for Real Application Clusters

4. Run the RSA_RAC.PREPARE_PLAN_ALL() procedure to build the partitioning

plan.
SQL> exec RSA_RAC.PREPARE_PLAN_ALL();
5. Review the actions performed by the RSA_RAC.PREPARE_PLAN_ALL()
procedure.
You can obtain the list of actions by querying the RSA_RAC_SUPPORT table.
SQL> SELECT table_name, statement_id, statement_text FROM
RSA_RAC_SUPPORT ORDER BY table_name, statement_id;
6. When the plan is approved and you are ready for the migration process, shut down
all the active application servers.
Note: The Adaptive Authentication system should not be active during the
execution process.
7. Execute the reviewed commands either manually or using the

RSA_RAC.RUN_PLAN_ALL() procedure that automatically runs the
commands.
SQL> exec RSA_RAC.RUN_PLAN_ALL();
If the execution failed for any reason, you can run the RUN_PLAN_ALL
procedure again. The procedure continues from the last command it handled.
For example, if the storage space was exhausted during the execution of the
RUN_PLAN_ALL procedure, it fails. As soon as more storage space is added,
you can run the procedure again.
8. Query the STATEMENT_STATUS column in the RSA_RAC_SUPPORT table to
ensure that the process completed successfully.
Make sure that the status of all records is 1.
SQL> SELECT DISTINCT statement_status FROM
rsa_rac_support;
9. Start the Adaptive Authentication (On-Premise) application servers.
Add Adaptive Authentication (On-Premise) RAC Support for a New

RAC Node
You must add RAC support in the following cases:
One of the RAC nodes was not active or the instance was shut down during the
execution of the RSA_RAC.PREPARE_PLAN_ALL() procedure.
A new RAC node was added to the cluster.
B: Support for Real Application Clusters 167

To add Adaptive Authentication (On-Premise) RAC support for an additional

node:
1. Make sure that all the RAC nodes are up and running.
2. Execute the RSA_RAC. ADD_NODE() procedure.
For example, while connected to Sql*Plus, type:
SQL> exec RSA_RAC.ADD_NODE();
168 B: Support for Real Application Clusters

Installation UpgradeGuide

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

Installation UpgradeGuide

Uploaded by

Copyright:

Available Formats

RSA Adaptive Authentication

Chapter 1: Prepare for Installation......................................................................11

Chapter 2: Installation Prerequisites ................................................................ 13

Chapter 3: Install Adaptive Authentication (On-Premise) ................... 23

Run SQL Scripts ........................................................................................................ 55

Chapter 4: Prepare to Upgrade ............................................................................ 65

Chapter 5: Upgrade from a Previous Version of Adaptive

Specify Back Office Connection Parameters for WebLogic ..................................... 93

Chapter 6: Complete a Dry-Run Upgrade ................................................... 103

Chapter 7: Configure Adaptive Authentication Applications ..........113

Chapter 8: Install and Configure Maintenance Utilities ...................... 133

Chapter 9: Install and Configure Development Utilities ..................... 153

Appendix A: Set Up the Application Servers ............................................ 157

Appendix B: Support for Real Application Clusters ............................. 165

About This Guide

RSA Adaptive Authentication (On-Premise) Documentation

Support and Service

Customer Support Information www.emc.com/support/rsa/index.htm

RSA Solution Gallery https://gallery.emc.com/community/marketplace/rsa?

RSA SecurCare Online offers a knowledgebase that contains answers to common

Before You Call Customer Support

1 Prepare for Installation

Database Sizing Guidelines

1: Prepare for Installation 11

The following factors may require additional disk space:

File System Log Sizing

12 1: Prepare for Installation

Installation Prerequisites for an Oracle Database

Creating a New Buffer Cache in Oracle

To create a new buffer cache if the database uses an SPFILE:

To create a new buffer cache if the database uses a PFILE:

4. Stop the database, as follows:

Installation Prerequisites for MS SQL Server

Create a system administrator account to access the database. The account

Important: Ensure that you have the latest build.

Installation Prerequisites for Unix Operating Systems

To set the limit of simultaneously opened files:

Installation Prerequisites for WebSphere

Installation Prerequisites for Tomcat

Locate the section that looks similar to the following:

Installation Prerequisites for BSafe

To apply the patch:

JDK Version Procedure

Installation Prerequisites for JBoss

Disable the CachedConnectionManager for the web server.

To disable the CachedConnectionManager for the web server:

To disable JSP pooling:

Adding a Separate Thread Pool for the Risk Engine

Installation Prerequisites for WebLogic

3 Install Adaptive Authentication

To extract the installation module:

3: Install Adaptive Authentication (On-Premise) 23

The Installation directory contains the following files to install Adaptive

Install Adaptive Authentication (On-Premise)

24 3: Install Adaptive Authentication (On-Premise)

To run the installation module on Windows:

To run the installation module at the command prompt on Windows:

To run the installation module on UNIX:

1. Change to the Installation directory where the installer program is located.

3: Install Adaptive Authentication (On-Premise) 25

Provide Preliminary Information

1. Read the information on the Welcome screen.

26 3: Install Adaptive Authentication (On-Premise)

6. On the Customer Information screen, in the Customer Name field, provide a