Skip to main content

Oracle E-Business Suite Password Management using FNDCPASS

Oracle E-Business Suite Password Management:

Before changing the APPS password using the FNDCPASS utility:
  • Take backup of table FND_USER and FND_ORACLE_USERID.
  • "alter user" command is not supported and should not be used for changing the apps password in any case.
  • Always use FNDCPASS to change the APPS password.
  • Check FNDCPASS log for any kind of error. If there is any error in the FNDCPASS log, then DO NOT run autoconfig or try to change configuration file manually.
  • Until and unless FNDCPASS log has no error, do not run autoconfig as you will get problem while logging in oracle application.
  • If there is and error in the FNDCPASS log, then either restore table FND_USER and FND_ORACLE_USERID to log into Applications or open SR to support with the FNDCPASS log.
  • If you are on Oracle E-Business Suite Release 12.1 or 12.2, ensure that your sqlnet_ifile.ora has the line
    SQLNET.ALLOWED_LOGON_VERSION_SERVER = 8
    (if the initialization parameter SEC_CASE_SENSITIVE_LOGON is set to FALSE)
    SQLNET.ALLOWED_LOGON_VERSION_SERVER = 10

    (if SEC_CASE_SENSITIVE_LOGON is set to TRUE)
    Passwords with special characters or multibyte characters are not currently supported with Oracle E-Business Suite.
  • The APPLSYSPUB password is an exception to the standardization of mixed case passwords, and must always be in upper case. This is true even if case-sensitive passwords have been enabled in Oracle Database 11g (SEC_CASE_SENSITIVE_LOGON=true).
Refer - Doc ID 1306938.1 FNDCPASS Troubleshooting Guide For Login and Changing Applications Passwords.
Oracle EBS provides two command line utilities:
  • FNDCPASS
  • AFPASSWD
for setting Oracle E-Business Suite schema passwords.
These utilities change the password registered in Oracle EBS tables and the schema password in the database.
The utilities can also be used to change user passwords.
Several important considerations apply:
• The Oracle E-Business Suite system must be shut down before you change a system schema (APPLSYS, APPS, APPS_NE) password.
• It is recommended that the FND_USER and FND_ORACLE_USERID tables are backed up before system passwords are changed.
Remove the backups after you have confirmed that the changes are successfully completed.
• After changing a system schema password with either FNDCPASS or AFPASSWD, you should run AutoConfig to synchronize the application tier files.
• If you are changing the APPLSYSPUB password using either FNDCPASS or AFPASSWD, you must change the value for the context variable s_gwyuid_pass and then run AutoConfig.
In Oracle E-Business Suite Release 12.2.3 and later, you can also use the AFPASSWD utility to migrate Oracle EBS user passwords to a non-reversible hash password scheme.
Refer - (Doc ID 457166.1)  R12: New Feature: Enhance Security With Non-Reversible Hash Password FNDCPASS
The FNDCPASS utility can be used to change various types of passwords.
Type 2 - Passwords for schemas that are used by shared components of Oracle EBusiness Suite (APPLSYS, APPS, APPS_NE); Also referred to as system passwords
Type 3 - Passwords for schemas that are provided by individual products within Oracle E-Business Suite
Note: You should always run AutoConfig after changing any system (type 2) password. 
Change Type 2 schema password:
All application tier services must first be shut down using the command
$INST_TOP/admin/scripts/adstpall.sh
SYSTEM mode changes the APPS and APPS_NE passwords as well as the APPLSYS password, and thereby keeps them all synchronized.

To change passwords for schemas that are used by shared components of Oracle E-Business Suite:

$ FNDCPASS <logon> 0 Y <SYSTEM username>/<SYSTEM password> SYSTEM <username> <new_password>

When specifying the SYSTEM token, FNDCPASS expects the next arguments to be the APPLSYS user name and the new password.
logon -  The Oracle user name.
<SYSTEM username>/<SYSTEM password> - The user name and password for the SYSTEM DBA account.
username - The Oracle user name. For example, 'GL'.
new_password - The new password.

FNDCPASS does the following:
1. Verifies the current APPLSYS password.
2. Re-registers password in Oracle E-Business Suite.
3. Changes the APPLSYS, APPS_NE, and all APPS passwords (for multi-APPS schema installations) to the same password.
4. ALTER USER is executed to change the ORACLE password for the above ORACLE users.
Changes the APPLSYS password:
$ FNDCPASS <APPS username> 0 Y <SYSTEM username>/<SYSTEM password> SYSTEM APPLSYS <new_password>

After changing the APPLSYS password, you must also perform the steps to Update WLS Data Source.
Execute FNDCPASS or AFPASSWD in system mode:
Whenever you use FNDCPASS or AFPASSWD in SYSTEM mode to change the APPS or APPLSYS schema passwords, you must also perform the actions listed below.

Note: Using SYSTEM mode with either APPLSYS or APPS will simultaneously update both the APPLSYS and APPS schemas: the respective passwords are kept in sync by both FNDCPASS and AFPASSWD.
Note: These steps must be performed on the run file system of the primary node.
1. Shut down the application tier services using the
$INST_TOP/admin/scripts/adstpall.sh
2. Change the APPLSYS password.
3. Start AdminServer using the
$INST_TOP/admin/scripts/adadminsrvctl.sh
Do not start any other application tier services.
4. Change the APPS password in WLS Data Source by running following script as shown:
$ perl $FND_TOP/patch/115/bin/txkManageDBConnectionPool.pl
When prompted, select 'updateDSPassword' to change the APPS password in the WLS Datasource.
5. Start all the application tier services using
$INST_TOP/admin/scripts/adstrtal.sh
6. Verify the WLS data source changes as follows:
1. Log in to the WLS Administration Console.
2. In the Domain Structure tree, expand Services, then select Data Sources.
3. On the Summary of JDBC Data Sources page, select EBSDataSource.
4. On the Settings for EBSDataSource page, select Monitoring >Testing.
5. Select "oacore_server1".
6. Click Test DataSource.
7. Look for the message "Test of EBSDataSource on server oacore_server1 was
successful".
Note: Steps 4, 5, and 6 are only applicable when changing the APPLSYS password. They are not applicable when changing passwords for product schemas or the SYSTEM schema.
In the next prepare phase after the password change, adop will invoke EBS Domain Configuration to ensure that the WLS data source on the patch file system will be synchronized with the new APPS password.


Run AutoConfig (adautocfg.sh) using <new_password> as the APPS password, and finally restart application tier services using the command
$INST_TOP/admin/scripts/adstrtal.sh


Changes the GL user password:
$FNDCPASS <APPS username> 0 Y <SYSTEM username>/<SYSTEM password> ORACLE GL <new_password>ORACLE Password:
Change Type 3, all ORACLE schema passwords:
Products that are registered as base product schemas in the FND_ORACLE_USERID table:
$FNDCPASS <logon> 0 Y <SYSTEM username>/<SYSTEM password> ALLORACLE <new_password>
When specifying the ALLORACLE token, FNDCPASS expects the next argument to be the new password.
logon - <username>/<password>
<SYSTEM username>/<SYSTEM password> - The user name and password for the SYSTEM DBA account.
new_password - The new password.

Changes all ORACLE schema passwords with prompt:
$FNDCPASS <APPS username> 0 Y <SYSTEM username>/<SYSTEM password> ALLORACLE <new_password>ORACLE Password:

Change an individual Oracle E-Business Suite user's password:
$FNDCPASS <logon> 0 Y <SYSTEM username>/<SYSTEM password> USER <username> <new_password>
When specifying the USER token, FNDCPASS expects the next arguments to be an Oracle E-Business Suite user name and the new password.
logon - The Oracle user name.
<SYSTEM username>/<SYSTEM password> - User name and password for System DBA account.
username - The Oracle E-Business Suite user name. For example, 'VISION'.
new_password - The new password.
Change password for the user VISION, with prompt:
$FNDCPASS <APPS username> 0 Y <SYSTEM username>/<SYSTEM password> USER VISION <new_password>
ORACLE Password:
$FNDCPASS APPS 0 Y <SYSTEM username>/<SYSTEM password> USER operations <password>
ORACLE Password:


Refer Doc ID 437260.1 - How To Change Applications Passwords Using Applications Schema Password Change Utility (FNDCPASS or AFPASSWD).

Comments

Popular posts from this blog

MySQL InnoDB cluster troubleshooting | commands

Cluster Validation: select * from performance_schema.replication_group_members; All members should be online. select instance_name, mysql_server_uuid, addresses from  mysql_innodb_cluster_metadata.instances; All instances should return same value for mysql_server_uuid SELECT @@GTID_EXECUTED; All nodes should return same value Frequently use commands: mysql> SET SQL_LOG_BIN = 0;  mysql> stop group_replication; mysql> set global super_read_only=0; mysql> drop database mysql_innodb_cluster_metadata; mysql> RESET MASTER; mysql> RESET SLAVE ALL; JS > var cluster = dba.getCluster() JS > var cluster = dba.getCluster("<Cluster_name>") JS > var cluster = dba.createCluster('name') JS > cluster.removeInstance('root@<IP_Address>:<Port_No>',{force: true}) JS > cluster.addInstance('root@<IP add>,:<port>') JS > cluster.addInstance('root@ <IP add>,:<port> ') JS > dba.getC

MySQL slave Error_code: 1032 | MySQL slave drift | HA_ERR_KEY_NOT_FOUND

MySQL slave Error_code: 1032 | MySQL slave drift: With several MySQL, instance with master slave replication, I have one analytics MySQL, environment which is larger in terabytes, compared to other MySQL instances in the environment. Other MySQL instances with terabytes of data are running fine master, slave replication. But this analytics environment get started generating slave Error_code :1032. mysql> show slave status; Near relay log: Error_code: 1032; Can't find record in '<table_name>', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log <name>-bin.000047, end_log_pos 5255306 Near master section: Could not execute Update_rows event on table <db_name>.<table_name>; Can't find record in '<table_name>', Error_code: 1032; Can't find record in '<table_name>', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log <name>-bin.000047, end_l

InnoDB cluster Remove Instance Force | Add InnoDB instance

InnoDB cluster environment UUID is different on node: To fix it stop group replication, remove instance (use force if require), add instance back Identify the node which is not in sync: Execute following SQL statement on each node and identify the node has different UUID on all nodes. mysql> select * from mysql_innodb_cluster_metadata.instances; Stop group replication: Stop group replication on the node which does not have same UUID on all nodes. mysql > stop GROUP_REPLICATION; Remove instances from cluster: Remove all secondary node from the cluster and add them back if require. $mysqlsh JS >\c root@<IP_Address>:<Port_No> JS > dba.getCluster().status() JS > dba.getCluster () <Cluster:cluster_name> JS > var cluster = dba.getCluster("cluster_name"); JS >  cluster.removeInstance('root@<IP_Address>:<Port_No>'); If you get "Cluster.removeInstance: Timeout reached waiting......" JS > cluster.removeInstance(&#