FNDCPASS – Best Practices and Tricks

In Oracle Application 11i and R12, we have an FND functionality for changing the passwords for either application user, or product schema password or most important – the “APPS” password. The FND binary which will help us is doing these things is FNDCPASS. This is present in $FND_TOP/bin directory.

This post explains the usage of FNDCPASS, best practices that needs to be followed while using FNDCPASS and some tricks when FNDCPASS screws up the instance :))

Using FNDCPASS 

Below is the usage for FNDCPASS

-bash-2.05b$ FNDCPASS
Usage: FNDCPASS logon 0 Y system/password mode username new_password
where logon is username/password[@connect]
system/password is password of the system account of that database
mode is SYSTEM/USER/ORACLE
username is the username where you want to change its password
new_password is the new password in unencrypted format
example FNDCPASS apps/apps 0 Y system/manager SYSTEM APPLSYS WELCOME
FNDCPASS apps/apps 0 Y system/manager ORACLE GL      GL1
FNDCPASS apps/apps 0 Y system/manager USER   VISION  WELCOME

You can just type FNDCPASS and press enter, it will give you these details.

The first usage

FNDCPASS apps/apps 0 Y system/manager SYSTEM APPLSYS WELCOME
is for changing the password for apps and applsys. These are the database schema users (most important for application to work). Password for both these users should be in synch. You can change the password of these users using this command. Note that this is the only way to change the password for apps and applsys. Please do not try any other method for changing apps and applsys password. Oracle recomends using FNDCPASS only to change apps and applsys password. Also note that using this command will change the password for both apps and applsys.

Following activities will take place

(1) applsys validation. (make sure APPLSYS name is correct)
(2) re-encrypt all password in FND_USER
(3) re-encrypt all password in FND_ORACLE_USERID
(4) update applsys’s password in FND_ORACLE_USERID table.
(5) Update apps password in FND_ORACLE_USERID table.

Also changes are made in DBA_USERS table.

The second usage

FNDCPASS apps/apps 0 Y system/manager ORACLE GL      GL1
is for changing password for any other product schema like MSC, GL etc.
Following activities will take place

(1) update GL’s password in FND_ORACLE_USERID table. The new password is re-encrypted with the current applsys password.

If GL does not exists, step (2) below does not happen. Message for invalid oracle user is written in the log file.

(2) alter user to change GL’s password.

The third usage

FNDCPASS apps/apps 0 Y system/manager USER   VISION  WELCOME
is for changing the application level passwords like sysadmin etc used for logging into application.

Following activities will take place

(1) update VISION’s password in FND_USER table. The new password is re-encrypted with the current applsys password.

If VISION does not exist, message for invalid application user is written in the log file.
No products affected by the patch

When you run FNDCPASS command it will check the integrity of all schema password in the application. If any of the password is corrupt then this will through and error and will not change the password.

The tables that it uses is FND_USER and FND_ORACLE_USERID. All the application passwords and schema passwords are stored in these two tables. Ofcourse DBA_USERS will have the schema users and password stored as well.

When we run FNDCPASS it will update all the above 3 tables.

Best practices for using FNDCPASS

Before using FNDCPASS and changing the passwords from default to some thing else, always follow the following best practices.

1) Always, Always, Always keep the back of tables FND_USER and FND_ORACLE_USERID. You can take back of these tables using CREATE TABLE — AS SELECT * FROM —.
You must have backup of these tables before running FNDCPASS. In case if FNDCPASS fails then it might corrupt the passwords of your application and worst can happen that the application wont come up. So always be cautions about this command.

2) If possible also keep an export dump of these two tables.

3) verify each arguement you are providing to FNDCPASS. Like verify that apps and system passwords you are providing is correct.

4) Never update apps, applsys or any schema password directly from database using the alter command. Always use FNDCPASS. System password can be set directly using ALTER command in database.

Issue with APPLSYS and APPS password

Scenario 1:

As you know that apps and applsys password should be in synch and should be changed using FNDCPASS.

There can be situation where a novice user changes applsys password from the backend database. In that case when you try to start the services it will show following error

APP-FND-01496: Cannot access application ORACLE password
Cause: Application Object Library was unable access your ORACLE password.

You can even reproduce this issue (ofcourse after taking the backup of FND_USER and FND_ORACLE_USERID table) using the following steps

1. Use the ALTER USER command to change the APPLSYS password

2. Try to run the adstrall.sh script to start Apps services.

3. You will get an error “Cannot complete applications logon. You may have entered an invalid applications password, or there may have been a database connect error.”

4. Then try FNDCPASS to fix password and you will get the error the APP-FND-01496 error.

If this situation happens then you cannot access the application. Infact the services even wont start.

Resolution to such problem is to rollback the 2 tables FND_USER and FND_ORACLE_USERID. Once you rollback the tables, apps and applsys passwords will be in synch and password will be older one. You can then run FNDCPASS and change the password.

Scenario 2:

Some times when you run FNDCPASS, you get following error

APP-FND-01502: Cannot encrypt application ORACLE password
Cause: Application Object Library was unable encrypt your ORACLE password.
Action: Contact your support representative. (ORACLEUSER=APPS_SERV)

The error comes because the table fnd_oracle_userid contain rows for schemas that does not exist. Those rows must be deleted from the table.

Use the following query to get the details of the schema that doest not exists

select * from fnd_oracle_userid
where oracle_username not in
(select username from all_users);

The rows returned by this query can be deleted from FND_ORACLE_USERID table. This will resolve this issue.

Scenario 3:

There can be situation where users has update APPLSYS password using ALTER command in database directly and also you dont have backup of those tables. Under such situation, it is very difficult to recover the application and make it working. Still following methodology is proposed which might help you to restore the password back and make your application work fine.

For this to work you should have some other application (may be debug or UAT) which is having the same passwords or default passwords for schemas. If you have such application the following the below steps in the application which is affected by password mismatch.
This method is for resetting apps and applsys passwords. Below are the SQL statements that will help you reset the APPS and APPLSYS passwords to APPS, the APPLSYSPUB password to PUB, and the SYSADMIN password to SYSADMIN.

WARNING: This procedure will cause all user passwords to become invalid. ALL users passwords will need to be reset through the sysadmin responsibility.

Step 1) Reset the Oracle User IDs

Open a SQL*Plus as SYSTEM and reset the passwords for the APPS, APPLSYS, and the APPLSYSPUB Oracle user ID:

   ALTER USER apps IDENTIFIED BY apps;
ALTER USER applsys IDENTIFIED BY apps;
ALTER USER applsyspub IDENTIFIED BY pub;

Step 2) Backup the FND_ORACLE_USERID and FND_USER tables (even though these tables are right now corrupted, do take a backup. You can restore the same when ever you want).

Open a SQL*Plus session as APPLSYS and backup the tables:

create table FND_ORACLE_USERID_BAK as (select * from FND_ORACLE_USERID);

create table FND_USER_BAK as (select * from FND_USER);

Step 3) Reset the APPS and APPLSYS application encrypted passwords

Open a SQL*Plus session as APPLSYS and update the FND_ORACLE_USERID table.

update FND_ORACLE_USERID
set ENCRYPTED_ORACLE_PASSWORD = ‘ZGA34EA20B5C4C9726CC95AA9D49EA4DBA8EDB705CB7673E645EED570D5447161491D78D444554655B87486EF537ED9843C8’
where ORACLE_USERNAME in (‘APPS’, ‘APPLSYS’);
commit;

This encrypted string we are updating is the default encrypted string for apps. So if your application is having apps password the encrypted string will look like this. We are updating this encrypted string here directly.

Verify the table update:

select ENCRYPTED_ORACLE_PASSWORD
from FND_ORACLE_USERID
where ORACLE_USERNAME IN (‘APPS’, ‘APPLSYS’);  

Step 4) Reset the APPLSYSPUB application encrypted password

Open a SQL*Plus session as APPLSYS and update the FND_ORACLE_USERID table.

update FND_ORACLE_USERID
set ENCRYPTED_ORACLE_PASSWORD = ‘ZG31EC3DD2BD7FB8AD2628CE87DDDF148C1D2F248BE88BE987FDF82830228A88EF44BC78BC7A9FAD4BFB8F09DAD49DF7280E’
where ORACLE_USERNAME = (‘APPLSYSPUB’);
commit;

The above encrypted string is the encrypted string for password pub. If your applsyspub password is pub then the encrypted string in FND_ORACLE_USERID will look like this.

Verify the table update:

select ENCRYPTED_ORACLE_PASSWORD
from FND_ORACLE_USERID
where ORACLE_USERNAME = ‘APPLSYSPUB’;

Once these updates are done, try your luck by running FNDCPASS and it should work fine.

Hope this help !!!

References

Metalink note ID 445153.1

Metalink note ID 429244.1
Oracle Apps Technology Blog

Advertisements

9 thoughts on “FNDCPASS – Best Practices and Tricks

  1. Hi Charlie,
    When we change Apps password (Applsys) not apps directly,then we need to bring down the Services.

    Othewise Frontend users password Like GL or SYSADMIN users can be changed directly,No need to bring down the apps services.

    Thanks
    Jyotirmay

  2. Hi Advait,

    This blog post is great and gives a clear understanding of FNDCPASS, i really appreciate your posting. I faced scenario 3 mentioned above, I have following query

    1. We took backup of FND_USER and FND_ORACLE_USERID tables
    2. Updated APPLSYS and APPS encrypted passwords using update statements.

    But since all the application user/schema passwords will be invalidated because of this procedure, solution suggested is to change them one by one from front-end, this is very cumbersome and also we will not know some of the users old passwords. If we change APPS password again with FNDCPASS will it correct the users entries in FND_USER and FND_ORACLE_USERID tables (by encrypting all the user passwords again with new applsys password) … or it will be of no use. Changing user passwords from front-end is the only way to go …? Please clarify.

    Thank you,
    Aditya

  3. Very Good Information. I was able to reslove the APPS password issue by following the Scenario 3:

    I have changed the APPS password from front end, and the table got corrupted. It got resolved after following the Scenario 3. Thanks for the information.

  4. Hello,

    I’m unable to change user password from frontend(FRM-40200:Field is protected against update.), and also not able change with FNDCPASS utility its stuck very long time and no o/p.

    Can you please help in this?

    Regards.
    M.F.H.

  5. Hi
    I have folloed Senario-3:

    Iam getting
    500 Internal Server Error

    Servlet error: An exception occurred. The current application deployment descriptors do not allow for including it in this response. Please consult the application log for details.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s