Removing Credentials From A Cloned EBS Production Database (Doc ID 419475.1)
Removing Credentials From A Cloned EBS Production Database (Doc ID 419475.1)
1
Copyright (c) 2020, Oracle. All rights reserved. Oracle Confidential.
In this Document
Abstract
History
Details
Step 1 - Clear All Credentials
Step 2 - Re-establish Bootstrap Credentials
Step 3 - Prepare Scripts for Setting Additional Passwords
Step 4 - Assign New Passwords to All Schemas Not Managed with EBS
Step 5 - Assign New Passwords to All Schemas Managed with EBS
Additional Steps
Running AutoConfig
References
APPLIES TO:
ABSTRACT
When cloning a Production database in Oracle E-Business Suite (EBS) it is a best practice to remove all Production account
credentials in the cloned copy of the database. This will help to prevent retrieval of Production credentials, which could be
used to compromise the security and integrity of the Production database.
It is ideal to complete this process as soon as possible after the database data files have been copied. At a minimum it should
be completed before the database is turned over to any party less trusted than the Production database DBA team.
This document describes the steps required to remove the Production EBS database credentials, such as database user
(schema) password hashes and encrypted passwords. Additionally information is provided about how to reestablish credentials
in the cloned copy so that the clone may be used for functional, performance or patch application testing.
Steps from this paper should be incorporated into your database cloning process and procedures.
HISTORY
Author :
Create Date 14-Mar-2007
Update Date 11-JUL-2011
Expire Date
DETAILS
1. Help to ensure that Production credentials are not retrievable from a cloned copy of an EBS Production database.
2. Boot strap the cloned copy with enough "clone credentials" that it may be used for testing.
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=106i0gj2cj_695&id=419475.1 1/8
3/12/2020 Document 419475.1
The steps in this document should be integrated in your database cloning process, see the "Reference" section below for
documentation on cloning EBS systems for Releases 11i and 12.
NOTE: In the examples below the data represents a fictitious sample (based upon made up data used in the Oracle
Demo Vision instance). Any similarity to actual persons, living or dead, is purely coincidental and not intended in any
manner.
The following sequence of steps will remove production account credentials from the cloned copy of the production database
and reestablish new credentials in the cloned copy. All of the new accounts on the clone target will have the password "clone".
Steps 1 through 4 are run on the database server running as the Operating System user, "oracle", using "sqlplus"
connected as the "SYS" or "APPS" database user. Step 5 is run as the Operating System user "applmgr" on an application tier
and uses the "FNDCPASS" command line utility. This means that steps 1 through 4 can be performed the first time the cloned
database is started, i.e. before it is made accessible to the network via the database TNS listener. Step 5 is not time critical
and can be performed when access to the cloned system for patch purposes is required.
To clear all credentials on a target clone of a production database you must establish a shell environment with sufficient
Oracle environment variables to successfully start "sqlplus" via the "BEQ" (bequeth) driver. If Rapid Clone has been
completed successfully, then each Oracle Home should have a <SID>.env file. However, in the event you need to set the
environment manually, here are the minimal environment settings:
$ export ORACLE_SID=<sid>
$ export ORACLE_HOME=<db-oraclehome>
$ export PATH=$ORACLE_HOME/bin
$ unset TWO_TASK
To clear all credentials in the cloned copy of a Production database, create and execute the following 3 SQL scripts:
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=106i0gj2cj_695&id=419475.1 2/8
3/12/2020 Document 419475.1
ENCRYPTED_USER_PASSWORD='INVALID'
/
commit;
At this point, the cloned copy of the database is free from Production credentials. The database was shut down by the script in
order for the unusual way of clearing the database user (schema) passwords to take effect. You will need to restart the cloned
copy of the database in preparation for steps 2, 3 and 4:
The database at the moment has no credentials. Now log on as "SYS" with operation system authentication. This will allow you
to establish new credentials.
Here is the script for step 2, including inline comments which explains what is done.
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=106i0gj2cj_695&id=419475.1 3/8
3/12/2020 Document 419475.1
begin
dummy := APPS.FND_PROFILE.SAVE('GUEST_USER_PWD', 'GUEST/CLONE', 'SITE');
if not dummy then
dbms_output.put_line( 'Error setting GUEST_USER_PWD profile' );
end if;
end;
/
commit;
REM One more time for luck (avoid session caching of profiles)
connect APPS/CLONE
User altered.
User altered.
User altered.
User altered.
User altered.
1 row updated.
1 row updated.
1 row updated.
Commit complete.
Connected.
RES
------
Y
Commit complete.
PL/SQL procedure successfully completed.
Commit complete.
Connected.
RES
------
Y
Commit complete.
It is important to verify that no errors are reported and that the 2 returned "RES" values are both "Y", whic
ATTENTION :
It has been identified, that some Customers running into an error for the SQL PLus command
In this case, please check Note 1350776.1 for the solution, before your are going ahead with the next steps !
Now we have completed establishing a set of bootstrap EBS credentials in the database.
In this step scripts are prepared to assign passwords to the other database users which were disabled in Step 1. Dynamically
generated scripts are used to accomplish this because the set of database users may differ between instances of EBS. Create
the script below and run it as the Operating System user "oracle":
REM Prepare SQL and SHELL scripts to set more passwords later
spool step3.lst
REM Generate a sql script to set password for db users not managed with EBS
REM Generate a shell script to set password for all base product schemas
REM Generate a shell script to set password for non-EBS db users managed with EBS
exit
NOTE: The script above calls the UNIX command "grep" to extract 2 sets of lines from the step3.lst spool file. If you
are running Windows, the shell redirection will fail when attempted from within sqlplus. You can perform the failed step by
going to a command prompt (using the HOST command from sqlplus). If you have your MKS environment set, then you can
use the "grep" syntax or alternatively you can use the below syntax from a Windows command (cmd.exe) prompt.
# alternative commands for extracting sql and shell commands from step3.lst
C:\ORACLE\Clone> findstr "^alter user " step3.lst > dbusers4.sql
C:\ORACLE\Clone> findstr "^FNDCPASS " step3.lst > dbusers5.cmd
Step 4 - Assign New Passwords to All Schemas Not Managed with EBS
Sample content of "dbusers4.sql" listed below for illustration purposes only, you must run the one you generated on your
system.
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=106i0gj2cj_695&id=419475.1 5/8
3/12/2020 Document 419475.1
Note: Prior to running your script, you should review the contents of the script for any obvious problems or syntax errors-
this is good advice for any dynamically-created SQL scripts.
Connect as "SYSDBA":
The output spool file should show many output lines stating "User altered.". No error messages (ORA-nnnnn) should
appear.
At this point, the database should be started and running. Stop and restart the database at this time. To ensure that the
application tier code can access the database for Step 5, you must also ensure that the database TNS-listener service is
running.
This step uses the "FNDCPASS" command to set the passwords for all the EBS managed schemas and all the base product
schemas. The "FNDCPASS" must be run from an application tier node.(Any node with an APPL_TOP file system.)
You will need to locate and copy the "dbusers5.sh" script from the directory where it was created in Step 3. Again, as with
any dynamcially generated scripts that you run on your system, you should review the contents of the file before running it.
Note for Windows users: In the unlikely event that any of the usernames contain the dollar sign "$" it has been escaped by
prefixing it by a backslash "\"; on Windows the backslash should be removed.
To run "FNDCPASS" you also need a number of environment variables set, at a minimum ensure that:
"FNDCPASS" is in the "$PATH" ("$ which FNDCPASS" will tell you if it is.)
The "ORACLE_HOME" environment variable points to the "Tools" ORACLE_HOME (8.0.6 on 11i, 10.1.2 on R12)
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=106i0gj2cj_695&id=419475.1 6/8
3/12/2020 Document 419475.1
The "TWO_TASK" environment variable is set to a value that can be resolved via the "$TNS_ADMIN/tnsnames.ora
file", in order to access the clone target database.
# Verify that the Oracle client environment is set to correct database (as "applmgr" OS user)
SYSDATE NAME
--------- ---------
25-JUL-07 PRD12
applmgr$ mkdir ~/s5 ; cd ~/s5 # create new directory to hold output files
applmgr$ sh dbusers5.sh # Run the FNDCPASS shell script
The following is sample content of a "dbusers5.sh" file is listed below for illustration purposes only, run the one you
generated on your system.
Each run of "FNDCPASS" will generate output an output/log file in the current working directory, you should review these log
files (example "L2763902.log") for errors.
NOTE: If your version of the "FNDCPASS" utility does not support the "ALLORACLE" mode, see "Q5" in the "Discussion"
section below.
To verify that you have assigned passwords to all the database users, run the following query and ensure that it does not
return any rows:
This concludes the clearing and re-establishment of account credentials from a cloned database. Please see the following 2
steps "Additional Steps" and "Running Autoconfig" before attempting to use the system.
Additional Steps
What remains to be done is to set new passwords for additional applications users or the creation of new test users,
depending on your needs. Changing passwords for applications users can be done using the "Define User" form (logged on as
"SYSADMIN/CLONE") or by running "FNDCPASS" with the below syntax from an "applmgr" applications shell environment.
You may also wish to change the passwords to something other than "clone". You can use modified versions of the scripts in
this note and you should reference the security best practices document for advice on changing passwords for an E-Business
Suite system, see the References section below.
Running AutoConfig
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=106i0gj2cj_695&id=419475.1 7/8
3/12/2020 Document 419475.1
Before you can actually start and access the cloned EBS system from the Application, a number of other configuration items,
such as system Profile Options, most likely need to be changed in the cloned environment. Items to change typically include:
The cloning notes, listed in the "Reference" section below, will provide you with information on how to run AutoConfig.
Running AutoConfig is a requirement and it must be run on all tiers of the cloned system to propagate password changes and
other changed settings into Autoconfig-managed files.
Prior to running AutoConfig ensure that the AutoConfig Context file contains the new "GUEST" password (Context variable
"s_guest_pass") and the new password for "APPLSYSPUB" (Context variable "s_gwyuid_pass").
REFERENCES
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=106i0gj2cj_695&id=419475.1 8/8