1. Administering Oracle GoldenGate Veridata
  2. Configuring Security

2 Configuring Security

Oracle GoldenGate Veridata provides a safe, secure environment for your business data by using Secure Sockets Layer (SSL) and plain socket communications. You can control your security by managing passwords and encrypting the report files.

This chapter includes the following topics:

Overview of Oracle GoldenGate Veridata Security

When using Oracle GoldenGate Veridata, you select, view, and store data values from the tables or files of your business applications. Ensure to protect access to the following components:

  • Files, programs, and directories in the Oracle GoldenGate Veridata installation directories. installation directories

  • Data files that contain the results of data comparisons

  • Oracle GoldenGate Veridata web user interface, where data values can be viewed

Configuring an SSL Connection between Oracle GoldenGate Veridata Server and Agents

Oracle GoldenGate Veridata supports SSL and plain socket communication between Oracle GoldenGate Veridata Server (server) and multiple Oracle GoldenGate Veridata Agents (agents) that are connected over a network. This section describes how to configure SSL and secure communication between the server and the agents.

Note:

The Oracle GoldenGate Veridata Agent for NonStop platforms doesn't support SSL communication.

In an SSL scenario, the server is considered the SSL Client and the agents are considered the SSL Servers. The server and the agents authenticate each other's identity. The data exchanged between the server and agent is also encrypted.

Configuring One-Way and Two-Way SSL Connections

SSL can be configured one-way or two-way in Oracle GoldenGate Veridata.

In a one-way SSL connection, the SSL client (Oracle GoldenGate Veridata Server) must trust the SSL server (Oracle GoldenGate Veridata Agent). In a two-way SSL connection, mutual trust is required between the SSL server and client. To enable SSL, you can use either self-signed certificates or Certificate Authority (CA) signed certificates.

To establish one-way SSL using self-signed certificates:

  1. Create self-signed certificates for all agents.

  2. Upload all agent certificates to the VeridataWebTrustStore of the server. See Managing the Server Identity and Trust Keystores.

To establish two-way SSL by using CA signed certificates:

  1. Create self-signed certificates for all agents.

  2. Upload all agent certificates to the VeridataWebTrustStore of the server.

  3. Create a self-signed certificate for the identity store of the server.

  4. Upload the server identity certificate to all agent truststores.

For more information about creating and importing certificates, see Creating Keystores and Self-Signed Certificates.

To establish one-way SSL by using CA signed certificates:

  1. Use certificates issued by the same CA for all agents.

  2. Trust the root CA certificate in the server.

To establish two-way SSL by using CA signed certificates:

  1. Use certificates issued by the same CA for all agents.

  2. Trust the root CA certificate in the server.

  3. Use the certificate issued by a CA for the identity store of the server.

  4. Trust the root CA certificate used in the previous step in the agent truststore.

Process for Enabling SSL

By default, the server and the agents are not enabled for SSL. If you decide to use SSL, you must enable the server and agent properties.

You must also create the identity and trust keystores. Create self-signed certificates if you are not using a CA certificate.

To establish an SSL connection between the server and the agent:

  1. Configure SSL for the server. See Configuring SSL Settings for the Oracle GoldenGate Veridata Server.

  2. Restart the server.

  3. Shut down the agent. Configure SSL for the agent. See Configuring SSL Settings for the Oracle GoldenGate Veridata Agent.

    1. Obtain the agent-side keystores. See Managing the Server Identity and Trust Keystores.

    2. Configure the agent-side keystores in the agent configuration properties file.

  4. Run configure_agent_ssl.sh and supply the password to the keystores configured in the agent configuration file. See Modifying the Oracle GoldenGate Veridata Agent Wallet.

  5. Start the agent.

  6. If the trust is established properly between agent keystores and their server counterpart in the Oracle Platform Security Services Keystore Service, then SSL communication is established.

Configuring SSL Settings for the Oracle GoldenGate Veridata Agent

By default, SSL is disabled for the agent. To configure SSL, edit the following properties in the agent.properties file for your agent.

Table 2-1 SSL Parameters in agent.properties file

Parameter Description Default Value

server.useSsl

Enables or disables SSL communication between the agent and the server. Possible values are:

  • true: Enables SSL communication
  • false: Disables SSL communication

false

server.use2WaySsl

Specifies whether the SSL communication false value is one way or two way. Options are:

  • true: Uses two-way SSL communication
  • false: Uses one-way SSL communication

false

server.identitystore.type

Specifies the type of keystore used for the SSL configuration.

JKS

server.identitystore.path

Specifies the path for the server identity keystore.

./certs/serverIdentity.jks(Self Signed)

server.truststore.type

Specifies the type of truststore used for SSL configuration.

JKS

server.truststore.path

Specifies the path for the server truststore.

./certs/serverTrust.jks(Self Signed)

server.identitystore.keyfactory.alg.name

Algorithm name of the keyfactory used for the SSL server identity store.

SunX509

server.truststore.keyfactory.alg.nam

Algorithm name of the keyfactory used for SSL server trust store.

SunX509

server.ssl.algorithm.name

SSL algorithm name.

Note: The value of this parameter must be same for the agent and the server.

TLS

Configuring SSL Settings for the Oracle GoldenGate Veridata Server

To enable SSL communication for all server-agent connections, you must set the SSL parameters in the veridata.cfg file located in the DOMAIN_HOME/config/veridata directory of your installation. Table 2-2 describes the various parameters that you must set in the veridata.cfg file for SSL communication.

To establish SSL communication only for certain connections, edit the connection properties in the Oracle GoldenGate Veridata web user interface. For more information, see the online help.

Note:

In addition to these settings, configure the server identity keystore and trust keystore by using the OPSS Keystore Service in the Oracle WebLogic Server domain. For more details, Managing the Server Identity and Trust Keystores.

Table 2-2 SSL Settings in the veridata.cfg file

Parameter Description Default Value

server.useSsl

Enables or disables SSL communication between the agent and the server. Possible values are:

  • true: Enables SSL communication
  • false: Disables SSL communication

false

server.ssl.client.identitystore.keyfactory.alg.name

Algorithm name of the keyfactory used for the SSL server identity store.

SunX509

server.ssl.client.truststore.keyfactory.alg.name

Algorithm name of the keyfactory used for the SSL server trust store.

SunX509

server.ssl.algorithm.name

SSL algorithm name.

Note: The value of this parameter must be the same for the agent and the server.

TLS

Creating Keystores and Self-Signed Certificates

For mutual authentication and to establish SSL communication, the server and the agents should mutually trust the add certificates in the respective truststores.

This section explains how to create keystores and self-signed certificates by using the keytool utility that is available as part of the Java Runtime Environment (JRE). For more details about keytool, refer to the Java documentation at http://docs.oracle.com/javase/7/docs/technotes/tools/#security.

Creating an Identity Keystore with a Self-Signed Certificate

To create a keystore containing a self-signed certificate:

  1. Enter 
    keytool -genkey -keystore certs -keyalg rsa -alias vdt_alias -storepass server_ks_pwd -keypass server_pwd

  2. At the prompts, enter the requested details about the certificate.

Building Server and Agent Keystores
  1. Build the agent keystore: 
    keytool -genkey -alias agent.server.keys -keyalg RSA -keystore agent.server.keystore -storepass ks_password -keypass keypwd
  2. Export the agent certificate to a file, run the following keytool command: 
    keytool -export -alias agent.server.keys -keystore agent.server.keystore -storepass ks_password -file agent.server.cer
  3. Build the server keystore, run the following keytool command:
    keytool -genkey -alias vdt.web.client.keys -keyalg RSA -keystore vdt.web.client.keystore -storepass ks_password -keypass keypwd
  4. Export the server certificate to a file, run the following keytool command: 
    keytool -export -alias vdt.web.client.keys -keystore vdt.web.client.keystore -storepass ks_password -file vdt.web.client.cer
Importing Certificates to the Server and Agent Truststores
  1. Import the server certificate to the agent truststore, enter: 
    keytool -import -v -keystore agent.server.truststore -storepass ks_password -file vdt.web.client.cer
  2. Import the agent certificate the server truststore, run the following keytool command: 
    keytool -import -v -keystore vdt.web.client.truststore -storepass ks_password -file agent.server.cer
Examples
Example 1   Create an Agent ID Keystore

keytool -genkey -alias vdt.agent.id -keyalg RSA -keystore vdtAgentID.jks -storepass changeit -keypass changeit -validity 365

C:\java\Java8\jdk1.8.0_40\bin>keytool -genkey -alias vdt.agent.id -keyalg RSA -keystore vdtAgentID.jks -storepass changeit -keypass c
hangeit -validity 365
What is your first and last name?
  [Unknown]:  COMPANY A
What is the name of your organizational unit?
  [Unknown]:  NA
What is the name of your organization?
  [Unknown]:  COMPANY A
What is the name of your City or Locality?
  [Unknown]:  USA
What is the name of your State or Province?
  [Unknown]:  USA
What is the two-letter country code for this unit?
  [Unknown]:  US
Is CN=COMPANY A, OU=NA, O=COMPANY A, L=USA, ST=USA, C=US correct?
  [no]:  yes

keytool -export -alias vdt.agent.id -keystore vdtAgentID.jks -storepass changeit -file vdtAgentID.cer

C:\java\Java8\jdk1.8.0_40\bin>keytool -export -alias vdt.agent.id -keystore vdtAgentID.jks -storepass changeit -file vdtAgentID.cer

The certificate is stored in the vdtAgentID.cer file.

Example 2   Create a Server ID Keystore

keytool -genkey -alias vdt.server.id -keyalg RSA -keystore vdtServerID.jks -storepass changeit -keypass changeit -validity 365

C:\java\Java8\jdk1.8.0_40\bin>keytool -genkey -alias vdt.server.id -keyalg RSA -keystore vdtServerID.jks -storepass changeit -keypass changeit -validity 365
 
What is your first and last name?
  [Unknown]:  ORACLE GOLDENGATE VERIDATA SERVER
What is the name of your organizational unit?
  [Unknown]:  NA
What is the name of your organization?
  [Unknown]:  COMPANY A
What is the name of your City or Locality?
  [Unknown]:  USA
What is the name of your State or Province?
  [Unknown]:  USA
What is the two-letter country code for this unit?
  [Unknown]:  US
Is CN=COMPANY A, OU=NA, O=COMPANY A, L=USA, ST=USA, C=US correct?
[no]:  yes

keytool -export -alias vdt.server.id -keystore vdtServerID.jks -storepass changeit -file vdtServerID.cer

C:\java\Java8\jdk1.8.0_40\bin>keytool -export -alias vdt.server.id -keystore vdtServerID.jks -storepass changeit -file vdtServerID.cer

The certificate is stored in the vdtAgentID.cer file.

Example 3   Create a TrustStore for Agent and Server

keytool -import -v -keystore vdtAgentTrust.jks -storepass changeit -file vdtServerID.cer -alias vdt.server.id

C:\java\Java8\jdk1.8.0_40\bin>keytool -import -v -keystore vdtAgentTrust.jks -storepass changeit -file vdtServerID.cer -alias vdt.ser
ver.id
Owner: CN=ORACLE GOLDENGATE VERIDATA SERVER, OU=NA, O=COMPANY A, L=USA, ST=USA, C=US
Issuer: CN=ORACLE GOLDENGATE VERIDATA SERVER, OU=NA, O=COMPANY A, L=USA, ST=USA, C=US
Serial number: 2aded02f
Valid from: Thu May 14 12:18:09 IST 2015 until: Fri May 13 12:18:09 IST 2016
Certificate fingerprints:
         MD5:  4E:7D:89:F7:C8:E8:64:37:E5:0C:D3:03:8F:3E:94:0A
         SHA1: 1B:00:9D:44:BD:73:6E:71:9D:44:56:4A:29:4E:F5:D7:1C:49:57:F3
         SHA256: 25:CB:77:3F:BC:5F:88:4B:09:D2:2D:C1:F8:E6:BA:70:DB:2B:55:53:48:7D:BA:F1:A3:01:18:AB:AA:D1:56:6A
         Signature algorithm name: SHA256withRSA
         Version: 3
 
Extensions:
 
#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: EF C3 25 BB 83 4E 2D 0D   15 3D EF 50 F7 F2 D0 A6  ..%..N-..=.P....
0010: 94 5F 87 F2                                        ._..
]
]
 
Trust this certificate? [no]:  yes
Certificate was added to keystore
[Storing vdtAgentTrust.jks]

keytool -import -v -keystore vdtServerTrust.jks -storepass changeit -file vdtAgentID.cer -alias vdt.agent.id

C:\java\Java8\jdk1.8.0_40\bin>keytool -import -v -keystore vdtServerTrust.jks -storepass changeit -file vdtAgentID.cer -alias vdt.age
nt.id
Owner: CN=COMPANY A, OU=NA, O=COMPANY A, L=USA, ST=USA, C=US
Issuer: CN=COMPANY A, OU=NA, O=COMPANY A, L=USA, ST=USA, C=US
Serial number: 6b590df2
Valid from: Thu May 14 12:08:00 IST 2015 until: Fri May 13 12:08:00 IST 2016
Certificate fingerprints:
         MD5:  3E:75:A3:96:40:60:10:96:DD:10:7B:4D:E4:3F:4C:04
         SHA1: D1:CC:EB:67:A1:C6:CD:CA:62:27:EA:F8:82:BF:AB:E4:E7:2B:45:6D
         SHA256: E7:20:CF:D4:48:E2:AE:1E:1C:C7:06:1A:B3:0A:17:1F:8F:02:88:B7:A6:A0:5D:F7:12:BC:26:68:5B:C3:C9:C8
         Signature algorithm name: SHA256withRSA
         Version: 3
 
Extensions:
 
#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: C0 D5 02 D9 24 6F 58 F6   63 D7 34 D3 9D C4 9E 33  ....$oX.c.4....3
0010: FC 16 4E 5F                                        ..N_
]
]
 
Trust this certificate? [no]:  yes
Certificate was added to keystore
[Storing vdtServerTrust.jks]

Managing the Server Identity and Trust Keystores

Use the Oracle Platform Security Services keystore service as a repository for storing the server identity and trust keystores. You can also use it to manage the agent keystores. For more information, see "Managing Keys and Certificates with the Keystore Service" in Oracle® Fusion Middleware Securing Applications with Oracle Platform Security Services .

Table 2-3 lists the default values for the OPSS settings.

Table 2-3 Oracle Platform Security Services Settings

Setting Value

Name of the application stripe created by the server

VeridataSec

Name of the identity keystore under the VeridataSec application stripe

VeridataWebIdentityStore

Name of the trust keystore under the VeridataSec application stripe

VeridataWebTrustStore

To configure two-way SSL by using the Oracle Platform Security Services keystore service:

  1. For each agent, create an identity and trust keystore.

  2. Update VeridataWebIdentityStore with the identity certificate of the server.

  3. Update VeridataWebTrustStore with all agent certificates.

  4. Update each agent truststore with the identity certificate of the server.

  5. Export the agent keystore and truststore as JKS files and note the passwords.

  6. Distribute the JKS files to corresponding agent machines.

  7. Run the configure_agent_ssl tool to update the agent wallet with the keystore passwords.

  8. For each agent, configure the agent.properties file to enable SSL.

To configure one-way SSL by using the Oracle Platform Security Services keystore service:

  1. For each agent, create an identity keystore.

  2. Update the VeridataWebIdentityStore with the identity certificate of the server.

  3. Export the agent keystore and truststore as JKS files and write down the passwords.

  4. Distribute the JKS files to corresponding agent machines.

  5. Run the configure_agent_ssl tool to update the agent wallet with the keystore passwords.

  6. For each agent, configure the agent.properties file to enable SSL.

Modifying the Oracle GoldenGate Veridata Agent Wallet

Before you start the agent in SSL mode, you must update the agent wallet with the identity and trust keystore passwords. Otherwise, the agent doesn't start.

To update the wallet:

  1. Run the configure_agent_ssl script that is available in the agent home: 

    AGENT_HOME\configure_agent_ssl.sh AgentID
    AgentID is the name of the agent properties file, without the .properties extension. The default value for AgentID is agent.

  2. At the prompts enter the entry or unlock password for the identity and trust keystores for the agent.

Securing the Oracle GoldenGate Veridata Files

This topic describes how to secure your business data and control access to the Oracle GoldenGate Veridata installation directories and user interface.

Controlling Access to the Installation Directories

Standard operating system permissions apply to the programs, files, and directories in the server, agent, and web user interface installation directories. You should adjust the permissions for these objects based on your business security rules.

Securing Files That Contain Business Data

The server creates data files that contain sensitive application data. By default, these files reside in DOMAIN_HOME/veridata/reports. The subdirectories contain files that may reflect business data.

The following types of files contain sensitive data:

  • Comparison report (rpt subdirectories)

  • Out-of-sync report (oosxml and oos subdirectories)

These files inherit the same file permissions as those of the user that runs the server installation program. Do not change the permissions; if you do, then Oracle GoldenGate Veridata may be unable to maintain them. Keep these files just as secure as you would keep your business data. Users of the Oracle GoldenGate Veridata web user interface do not require access to these files because they see the same information through the client interface. You can encrypt the contents of all report files.

Securing Access to Oracle GoldenGate Veridata by Defining User Roles

You assign security roles to control user access to the software functions, some of which expose selected data values from the database.

Oracle GoldenGate Veridata Type Description

veridataAdministrator

Type-A

The administrator role is the highest level security role. This role can perform all functions that configure, execute, and monitor Oracle GoldenGate Veridata.

veridataPowerUser

Type-A

The power user role is the second highest role. This role can perform all functions that configure, execute, and monitor Oracle GoldenGate Veridata from the web user interface. It cannot perform any configuration functions for the server.

veridataReportViewer

Type-B

The report viewer role cannot perform functions that configure Oracle GoldenGate Veridata or execute jobs. This role can only view configuration and job information, and view comparison reports.

veridataDetailReportViewer

Type-B

The detail report viewer role cannot perform any functions that configure Oracle GoldenGate Veridata or execute jobs. This role can only view configuration and job information. It can also view comparison reports and out-of-sync report information through the web user interface or at the file level.

veridataRepairOperator

Additional

The repair operator role can use the Repair feature in Oracle GoldenGate Veridata.

veridataCommandLineUser

Additional

The command-line user role provides access to the Oracle GoldenGate Veridata command-line tools, vericom, and the Oracle GoldenGate Veridata import and export utilities.

These roles are categorized into as follows:

  • Type A and Type B: By default, Type A and Type B users are not given any privileges of the additional user roles. Assign additional roles to users of these types.

  • Additional: WebLogic Administrators can assign these Additional roles to Type A users to perform the required Oracle GoldenGate Veridata functions.

Security is controlled through the Oracle WebLogic Server Administration Console, where a user with the administrator role can:

  • Create a user and assign it a security role.

  • Create user groups and assign them security roles. Users can be added to these groups without being given a security role. A user inherits the role of its group.

  • Create a user and assign it a security role, and then add that user to a group. The user inherits the role of its group and keeps its individual role.

Setting Up Active Directory Users on Oracle GoldenGate Veridata

To set up Active Directory Users on Oracle GoldenGate Veridata:

  1. In the Oracle WebLogic Server Administration Console, navigate to Security Realms, then select myrealm , and then click Roles and Policies.

  2. Select the Realm Roles subtab.

  3. Expand Global Roles and then click on Roles link from the table.
  4. Click New to create  the following Roles:
    1. ExtAdministrator
    2. ExtPowerUser
    3. ExtDetailReportViewer
    4. ExtReportViewer
    5. ExtReportViewer
Oracle GoldenGate Veridata Type Description
ExtAdministrator

Type-A

The ExtAdministrator role is the highest-level security role in Oracle GoldenGate Veridata. This role can perform all of the functions that configure, execute, and monitor Oracle GoldenGate Veridata.

ExtPowerUser

Type-A

The ExtPowerUser role is the second-highest role in Oracle GoldenGate Veridata. This role can perform all of the functions that configure, execute, and monitor Oracle GoldenGate Veridata from the Oracle GoldenGate Veridata Web User Interface, but this role cannot perform any configuration functions for the Oracle GoldenGate Veridata Server.

ExtReportViewer

Type-B

The ExtReportViewer role cannot perform functions that configure Oracle GoldenGate Veridata or execute jobs. This role can only view configuration and job information, and view comparison reports.

ExtDetailReportViewer

Type-B

The ExtDetailReportViewer role cannot perform any functions that configure Oracle GoldenGate Veridata or execute jobs. This role can only view configuration and job information, and view comparison reports and out-of-sync report information through the Oracle Oracle GoldenGate Veridata web user interface or at the file level.

ExtRepairOperator

Additional

The ExtRepairOperator role can use the Repair feature in Oracle GoldenGate Veridata.

To open the Oracle WebLogic Server Administration Console:

  1. In your browser, connect to the Oracle WebLogic Server Administration Console by entering the following address:
    http://weblogic_admin_server_hostname:admin_server_port/console

    weblogic_admin_server_hostname is the name or IP address of the system where the server and web components are hosted, and admin_server_port is the port number assigned to the server (default is 7001).

  2. Log on as an Oracle GoldenGate Veridata administrator user. A default administrator user was created when the Oracle GoldenGate Veridata domain was set up.

To create or edit a user:

  1. In the left pane of the Oracle WebLogic Server Administration Console, select Security Realms.
  2. On the Summary of Security Realms page select the name of the security realm.
  3. On the Settings for Veridata Security realm page, select Users and Groups, and then select Users. The User table displays the names of all users defined in the Authentication provider.
  4. Select an existing user and edit the settings or click New to create a user and enter the user’s properties.
  5. To assign a role to the user, click Groups on the Settings for user_name page.

    Select appropriate roles for the user.

    For example, an administrator, VeridataAdmin, can be given the privileges shown in the figure.

    veridata user roles

    For example, a Veridata power user, PowerUser, can be given the privileges shown in the next figure.

    power user

  6. Click Save .

Changing Database Schema Passwords

You can change database schema passwords when a schema password expires, an account is locked, or a password change is necessary. This topic applies to all database schemas that are prefixed with 'OGG', such as OGG_IAU, OGG_IAU_APPEND, or OGG_IAU_VIEWER.

T change a database schema password:

  1. Stop your Oracle GoldenGate Veridata Server. 

    DOMAIN_HOME/veridata/veridata/bin/veridataServer.sh stop

  2. Stop your Oracle WebLogic Server.

    DOMAIN_HOME//veridata/bin/stopWebLogic.sh

  3. Start the Oracle WebLogic Scripting Tool, wlst.sh. For example: 

    /home/oracle/Oracle/Middleware/Oracle_Home/oracle_common/common/bin/wlst.sh

  4. Modify the database schema password as in this example:

    modifyBootStrapCredential(jpsConfigFile='/home/oracle/wls_domains/veridata/config/fmwconfig/jps-config.xml',username='OGG_OPSS',password='welcome123')

    username= is your database schema name and password= is the new password.

  5. Exit the scripting tool by using exit().

  6. Log in to the metadata repository database and change the schema passwords and unlock the schema.

    The following example that unlocks the OGG_OPSS schema:
    alter user OGG_OPSS identified by welcome123; 
alter user OGG_IAU identified by welcome123; 
alter user OGG_IAU_APPEND identified by welcome123; 
alter user OGG_IAU_VIEWER identified by welcome123; 
alter user OGG_STB identified by welcome123; 
alter user OGG_VERIDATA identified by welcome123; 
alter user OGG_OPSS account unlock;

  7. Start the Oracle WebLogic Server Configuration Wizard. For example:

    /home/oracle/Oracle/Middleware/Oracle_Home/oracle_common/common/bin/config.sh

  8. Select Update an Existing Domain, and then click Next.

  9. Select JDBC Component Schema, and then enter the new database schema passwords.

  10. Click Next until you reach the Configuration Summary screen, and then click Update.

  11. To save your schema password changes, click Next and then Finish.

  12. Start Oracle WebLogic Server.

    DOMAIN_HOME//veridata/bin/startWebLogic.sh

  13. Start your Oracle GoldenGate Veridata Server. 

    DOMAIN_HOME/veridata/veridata/bin/veridataServer.sh start

Encrypting Report Files

You can encrypt the comparison report files (.rpt, .oos, .oosxml) in Oracle GoldenGate Veridata. The following sections explain report encryption:

Enabling Report Encryption

The encryption is controlled by the following parameters in the veridata.cfg configuration file:

  • server.encryption

  • server.encryption.bits

To enable encryption, set server.encryption to true.

Encryption of report files uses Advanced Encryption Standard (AES) encryption, and the default encryption strength is 128 bits. You can increase the encryption strength to 192 or 256 bits by editing the value of the server.encryption.bits parameter in veridata.cfg. However, for encryption strength greater than 128, you must use a JRE installed with the Unlimited Strength Cryptography Extension.

For more information about these parameters, see "Parameters for Report File Encryption".

Encrypted report files have the following extensions in the file names:

  • .xrpt : Encrypted comparison or repair report file

  • .xoos: Encrypted binary out-of-sync file

  • .xoosxml: Encrypted out-of-sync XML file

  • .xNNN: Encrypted out-of-sync XML chunk file (NNN is a decimal number)

Displaying Encrypted Files with the reportutil Utility

When report encryption is enabled, all report files are encrypted by using an encryption key, which is initially a large random value. If necessary, then you can change the encryption key.

Before you can read encrypted files, you must decrypt them. The Oracle GoldenGate Veridata web user interface automatically decrypts files before displaying them. Use the reportutil.sh/.bat utility to display the encrypted contents. This utility is located in the VERIDATA_DOMAIN_HOME\veridata\bin directory.

To display encrypted files, run the reportutil.sh/.bat utility located in the VERIDATA_DOMAIN_HOME\veridata\bin directory. 

reportutil   [-wlport port ] -wluser weblogic_user { options }

wlport is the server port number (the default port is 8830), and wluser is the server user name.

The valid options are:

  • -version, -v: Displays the current version

  • -help: Displays the help message

  • -r: Rolls report encryption

  • -f filename [-d directory]: Decrypts and prints the report file to the specified file if a directory is specified by the -d option. Otherwise, the command prints the decrypted file to the standard output.

The user running the reportutil utility must be in the appropriate user group to perform the operations:

  • -r, -f: Allowed only if the user is a member of the veridataCommandLineUser group.

  • -r: Allowed if the user is a member of the veridataAdministrator group.

  • -f: Allowed if the user is a member of the veridataAdministrator group, or a member of veridataPowerUser group, the veridataPowerUser group, or the veridataDetailReportViewer group.

For more information about the user roles, see Securing Access to Oracle GoldenGate Veridata by Defining User Roles.