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:

2.1 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.
Data files that contain the results of data comparisons
Oracle GoldenGate Veridata web user interface, where data values can be viewed

2.2 Configuring SSL Connection between Oracle GoldenGate Veridata Server and Agents

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

In SSL scenario, the Oracle GoldenGate Veridata 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.

Oracle GoldenGate Veridata supports both One-Way and Two-Way SSL connections.

This topic describes the following:

2.2.1 One-Way SSL Connection

In one-way SSL connection, the SSL client (Oracle GoldenGate Veridata Server) must trust the SSL server (Oracle GoldenGate Veridata Agent).

To enable SSL, you can use either self-signed certificates OR Certificate Authority (CA) signed certificates.

Using Self-Signed Certificates

Create self-signed certificates for all agents using keytool API. Keytool is a Java API that comes along with Java Installation. See Generating Self-Signed Keystores and Truststores for generating self-signed certificates.
Edit agent.propeties for SSL configurations. See Configuring SSL Settings for the Oracle GoldenGate Veridata Agent.
Update Agent Wallet. See Updating Oracle GoldenGate Veridata Agent Wallet.
Start Oracle GoldenGate Veridata Agent.
Edit Server Configuration file. See Configuring SSL Settings for the Oracle GoldenGate Veridata Server (This step is optional. Use it if SSL connection should be established with all agents. For individual agents, SSL checkbox can be checked from UI under Connection Configuration )
Upload the TrustStore generated in Step 1 to the VeridataWebTrustStore. See Updating Oracle GoldenGate Veridata Server Trust Store.

Using CA Signed Certificates

Use certificates issued by the same CA for all agents.
Copy the certificates under <Agent_Home>/config/certs directory.
Edit agent.propeties for SSL configurations. Configuring SSL Settings for the Oracle GoldenGate Veridata Agent.
Update Agent Wallet. See Updating Oracle GoldenGate Veridata Agent Wallet.
Start Oracle GoldenGate Veridata Agent.
Edit Server Configuration file. See Configuring SSL Settings for the Oracle GoldenGate Veridata Server (This step is optional. Use it if SSL connection should be established with all agents. For individual agents, SSL checkbox can be checked from UI under Connection Configuration ).
Trust the Agent root CA certificate in the server. See Updating Oracle GoldenGate Veridata Server Trust Store.

2.2.2 Two-Way SSL Connection

In two-way SSL, mutual trust is needed between Veridata Server and Agents for the SSL connection to be established. To enable SSL, you can use either self-signed certificates OR Certificate Authority (CA) signed certificates.

Using Self-Signed Certificates

Create self-signed certificates for all agents and Veridata Server. See Generating Self-Signed Keystores and Truststores for generating self-signed certificates.
Edit agent.properties. See Configuring SSL Settings for the Oracle GoldenGate Veridata Agent.
Update Veridata Agent Wallet. See Updating Oracle GoldenGate Veridata Agent Wallet.
Start Agent(s).
Edit Server Configuration file. See Configuring SSL Settings for the Oracle GoldenGate Veridata Server.
Upload all agent certificates to the VeridataWebTrustStore and Server Identitity certificate to VeridataWebIdentityStore of the Veridata Server. See Updating Oracle GoldenGate Veridata Server Trust Store.

Using CA Signed Certificates

Use certificates issued by the same CA for all agents.
Copy both AgentID and AgentTrust certificates under <Agent_Home>/config/certs directory.
Edit agent.properties. See Configuring SSL Settings for the Oracle GoldenGate Veridata Agent.
Update Veridata Agent Wallet. See Updating Oracle GoldenGate Veridata Agent Wallet.
Start Veridata Agent(s).
Edit Server Configuration file. See Configuring SSL Settings for the Oracle GoldenGate Veridata Server.
Trust the root CA certificate in the server. See Updating Oracle GoldenGate Veridata Server Trust Store.

2.2.3 Generating Self-Signed Keystores and Truststores

Build Agent Keystore:

keytool -genkey -alias agent.server.keys -keyalg RSA -keystore vdtAgentIdentity.jks -storepass ks_password -keypass keypwd

Copy the vdtAgentIdentity.jks generated to <Agent_Home>/config/certs directory.

Export Agent Keystore to a certificate:

keytool -export -alias agent.server.keys -keystore vdtAgentIdentity.jks -storepass ks_password -file agent.server.cer

Import the agent certificate to server truststore:

keytool -import -v -keystore serverTrust.jks -storepass ks_password -file agent.server.cer

Copy serverTrust.jks to the box where Veridata Server is running.

The following points are for two-way SSL:

On a system where you have installed Oracle GoldenGate Veridata server, build the server keystore:

keytool -genkey -alias vdt.web.client.keys -keyalg RSA -keystore vdtServerID.jks -storepass ks_password -keypass keypwd

Export the server certificate to a file:

keytool -export -alias vdt.web.client.keys -keystore vdtServerID.jks -storepass ks_password -file vdt.web.client.cer

Import the server certificate to the agent truststore:
```
keytool -import -v -keystore vdtAgentTrust.jks -storepass ks_password -file vdt.web.client.cer
```
Copy vdtAgentTrust.jks to all the Agent box under <Agent_deployed_location>/config/certs.

Following examples illustrate how to generate Keystore via Java Keytool:

Example 1: Create an Agent ID Keystore

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

Copy
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?

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

Copy 
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

Copy
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

Copy
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 vdtServerID.cer file.

Create a TrustStore for Oracle GoldenGate Veridata Agent and Oracle GoldenGate Veridata Server

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

Copy
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

Copy
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]

Renew the new Certificate from an Existing Certificate

To renew a new Truststore certificate, you need to first delete the existing truststore and then create a new TrustStore for Agent and Server

To delete the existing truststore from Oracle WebLogic by using the WLST script and creating a new Truststore:

Execute <Oracle_Home>/oracle_common/bin/wlst and execute the following commands to delete the existing certificate:

connect(url='t3://<host>:<admin port>')
svc = getOpssService(name='KeyStoreService')
svc.listKeyStores(appStripe='*')
svc.deleteKeyStore(appStripe='stripe', name=<'keystore'>,
password=<'password'>)

After you have deleted it, create a new certificate by following the example Create a TrustStore for Oracle GoldenGate Veridata Agent and Oracle GoldenGate Veridata Server.

2.2.4 Configuring SSL Settings for the Oracle GoldenGate Veridata Agent

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

Table 2-1 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.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.	`./config/certs/ vdtAgentIdentity.jks` (Self Signed)
`server.truststore.path`	Specifies the path for the server truststore.	`./config/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

2.2.5 Updating Oracle GoldenGate Veridata Agent Wallet

Ensure agent.properties is updated as explained in Configuring SSL Settings for the Oracle GoldenGate Veridata Agent before running this script. Run configure_agent_ssl script that is available in the agent home as follows:

AGENT_HOME\configure_agent_ssl.sh AgentID

AgentID is the name of the agent properties file, without the .properties extension.

The following questions are prompted:

Enter Agent Identity Store unlock password :<Specify the storepassword > 
Enter Agent Identity Store entry password: <Specify the keypassword>
Enter Agent Trust Store unlock password: <Specify the storepassword>

2.2.6 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. To establish SSL communication only for certain connections, edit the connection properties in the Oracle GoldenGate Veridata web user interface.

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

2.2.7 Configuring an SSL Connection between Oracle GoldenGate Veridata Server and NonStop Agent

To configure an SSL Connection between Oracle GoldenGate Veridata Server and NonStop Agent:

Create a new certificate file for the Nonstop agent and name it SSLCERT to replace the sample certificate file that exists in the Nonstop agent.
On Veridata Server, generate a jks file based on a certificate file of NonStop agent from step 1 by using the following command:
```
keytool -import -v -keystore vdtServerTrust.jks -storepass <create_your_own> -file SSLCERT -alias <create_your_own>
```
Edit the Server Configuration file. See Configuring SSL Settings for the Oracle GoldenGate Veridata Server.
Follow the instructions in topic Updating Oracle GoldenGate Veridata Server Trust Store (except for step 6, to import the jks file to the Veridata server).

2.2.8 Updating Oracle GoldenGate Veridata Server Trust Store

Copy the Trust Certificate (serverTrust.jks in-case of SelfSigned/rootCA for CA Signed) generated earlier to any folder on Server.
Execute WLST script present under <OracleHome>/oracle_common/common/bin. This allows you to login to WLST tool in offline mode.
Connect to Admin Server from WLST console. Ensure Weblogic is up and running for the connection to be successful: connect(url='t3://<host>:<port>'). You are prompted for Weblogic credentials.

Run the following in WLST console:

svc = getOpssService(name='KeyStoreService')
svc.listKeyStores(appStripe='*')

The following should be seen in the output:

VeridataSec/VeridataWebTrustStore
VeridataSec/VeridataWebIdentityStore

Run the following command to import the generated Truststore in above step to VeridataWebTrustStore:

svc.importKeyStore(appStripe='VeridataSec', name='VeridataWebTrustStore',
          password='storepass', aliases= 'agent.server.keys', keypasswords='keypass', type='JKS',
          permission=true, filepath='<path to Truststore file copied in step
        1>')

In case of 2-way SSL, import ServerID to VeridataWebIdentityStore.

svc.importKeyStore(appStripe='VeridataSec', name='VeridataWebIdentityStore',
          password='storepass',aliases='vdt.web.client.keys', keypasswords='keypass', type='JKS',
          permission=true, filepath='<path to ServerIdentity file created in section
          2.2.3>')

Run exit() command to exit WLST tool
Restart Admin and Managed Server.

2.3 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.

2.4 Securing Access to Oracle GoldenGate Veridata by Defining User Groups

You assign security groups 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 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 Groups on Oracle GoldenGate Veridata

To set up Active Directory groups on Oracle GoldenGate Veridata:

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).
Log on as an Oracle GoldenGate Veridata administrator user. A default administrator user was created when the Oracle GoldenGate Veridata domain was set up.
In the Oracle WebLogic Server Administration Console, navigate to Security Realms, then select myrealm , and then click Roles and Policies.
Select the Realm Roles subtab.
Expand Global Roles and then click on Roles link from the table.

Click New to create the following Roles:

ExtAdministrator
ExtPowerUser
ExtDetailReportViewer
ExtReportViewer
ExtRepairOperator

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.

You can create a new role as shown in the following screen shot:

Figure 2-1 Global Roles

For example, consider ExtAdministrator role.

Figure 2-2 Example: ExtAdministrator role

Enter the Role Name and click OK.
Similarly, create all 5 Roles.
After all the Roles are created, navigate to Global Roles Table and select the role for which Active Directory group should be mapped and then click Edit Role, and then click Next.

Figure 2-3 Active Directory Roles
Click Add Conditions button and then select Group from Predicate List and click Next.

Figure 2-4 Editing a Role
Enter the Active Directory group in Group Argument Name, click Add , click Finish, and then click Save to save the changes. For example, enter the Group Argument Name as Finance. After this group gets added, all users part of the group will have Oracle GoldenGate Veridata access.

Figure 2-5 Edit Arguments

2.5 Creating and Editing Users

You can create and edit users in the WebLogic Console.

To create and edit users:

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).
In the left pane of the Oracle WebLogic Server Administration Console, select Security Realms.
On the Summary of Security Realms page select the name of the security realm.
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.
Select an existing user and edit the settings or click New to create a user and enter the user’s properties.
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.

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

2.6 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.

To change a database schema password:

Shutdown the Administration Server and Oracle GoldenGate Veridata Server.
```
DOMAIN_HOME/veridata/veridata/bin/veridataServer.sh stop
```

Run the following sql queries to change the password and unlock the OPSS schema:

alter user
{SCHEMA_PREFIX}_IAU identified by {NEW_PASSWORD};
alter user {SCHEMA_PREFIX}

_IAU_APPEND identified by
{NEW_PASSWORD};
alter user {SCHEMA_PREFIX}_IAU_VIEWER identified by {NEW_PASSWORD}

;
alter user
{SCHEMA_PREFIX}_STB identified by {NEW_PASSWORD};
alter user {SCHEMA_PREFIX}

_VERIDATA identified by
{NEW_PASSWORD};
alter user {SCHEMA_PREFIX}_WLS identified by {NEW_PASSWORD}

;
alter user
{SCHEMA_PREFIX}_WLS_RUNTIME identified by {NEW_PASSWORD};

alter user {SCHEMA_PREFIX}

_OPSS identified by
{NEW_PASSWORD};
alter user {SCHEMA_PREFIX}_OPSS account unlock;

Navigate to the following directory:

{ORACLE_HOME}/oracle_common/common/bin . Run ./wlst.sh

Execute the following:

modifyBootStrapCredential(jpsConfigFile='{DOMAIN_HOME}/config/fmwconfig/jps-co
nfig.xml',username='{SCHEMA_PREFIX}_OPSS',password='{NEW_PASSWORD}

')

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

Execute: exit().

Navigate to run:

{SCHEMA_PREFIX}

_STB details in "Database Configuration Type"

In the Component Datasources page, select all the components and enter the new password if the password is same for all schemas . If the password is different for each schema, then select each schema and enter the password. Ensure to check, change password, and then uncheck for each component.
Execute the JDBC Test and make sure it is successful.
Complete the configuration.
Start the Administration Server.

Start your Oracle GoldenGate Veridata Server.

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

2.7 Encrypting Report Files

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

2.7.1 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 JSON chunk file (NNN is a decimal number)

2.7.2 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 Groups.