FNDCPASS doesn’t always use the SYSTEM password
Chuck Edwards | | April 21, 2009

FNDCPASS does not check the system password when used to change an application’s user account. We can check this with a simple test.
First, we’ll change the SYSTEM password to the default value “manager”:
[applmgr@appsrv01 ~]$ sqlplus system
SQL*Plus: Release 8.0.6.0.0 - Production on Thu Apr 23 13:10:17 2009
(c) Copyright 1999 Oracle Corporation. All rights reserved.
Enter password:
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Production
With the Partitioning, OLAP and Data Mining Scoring Engine options
SQL> alter user system identified by manager;
User altered.
SQL> exit
Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Production
With the Partitioning, OLAP and Data Mining Scoring Engine options
[applmgr@appsrv01 ~]$
Next, we’ll use FNDCPASS to change the SYSADMIN application password using an incorrect value for the SYSTEM password:
[applmgr@appsrv01 ~]$ FNDCPASS apps/apps 0 Y system/badpassword USER SYSADMIN sysadmin
Log filename : L4203491.log
Report filename : O4203491.out
If we cat the log file, we can see the password change was successful:
[applmgr@appsrv01 ~]$ cat L4203491.log
+---------------------------------------------------------------------------+
Application Object Library: Version : 11.5.0
Copyright (c) 1979, 1999, Oracle Corporation. All rights reserved.
module:
+---------------------------------------------------------------------------+
Current system time is 23-APR-2009 13:11:39
+---------------------------------------------------------------------------+
+---------------------------------------------------------------------------+
Concurrent request completed successfully
Current system time is 23-APR-2009 13:11:39
+---------------------------------------------------------------------------+
Next, we’ll try to change the GL schema password using the same incorrect SYSTEM password:
[applmgr@appsrv01 ~]$ FNDCPASS apps/apps 0 Y system/badpassword ORACLE GL gl
Log filename : L4203493.log
Report filename : O4203493.out
This time, the log shows failure because of an inability to connect as SYSTEM:
[applmgr@appsrv01 ~]$ cat L4203493.log
+---------------------------------------------------------------------------+
Application Object Library: Version : 11.5.0
Copyright (c) 1979, 1999, Oracle Corporation. All rights reserved.
module:
+---------------------------------------------------------------------------+
Current system time is 23-APR-2009 13:12:15
+---------------------------------------------------------------------------+
SECURITY-UNABLE TO CONNECT TO SYSTEM
APP-FND-01564: ORACLE error 1403 in changepassword
Cause: changepassword failed due to ORA-01403: no data found.
The SQL statement being executed at the time of the error was: and was executed from the file &ERRFILE.
+---------------------------------------------------------------------------+
Concurrent request completed
Current system time is 23-APR-2009 13:12:15
+---------------------------------------------------------------------------+
It appears that FNDCPASS only uses the SYSTEM password when changing a database account, which makes sense, since only the APPS password is required to execute FND_WEB_SEC and change a password in FND_USER.
Subscribe to Our Blog
Never miss a post! Stay up to date with the latest database, application and analytics tips and news. Delivered in a handy bi-weekly update straight to your inbox. You can unsubscribe at any time.
Popular Posts
ORA-12154: TNS:could not resolve the connect identifier specified
Most people will encounter this error when their application tries to connect to an Oracle database service, but it can also be raised by one database instance trying to connect to another database service via a database link.
12c Upgrade Bug with SQL Tuning Advisor
Learn the steps to take on your Oracle upgrade 11.2 to 12.1 if you’re having performance problems. Oracle offers a patch and work around to BUG 20540751.
Scripting Out the Logins, Server Role Assignments, and Server Permissions
Imagine over 100 logins on the source server, you need to migrate them to the destination server. Wouldn’t it be awesome if we could automate the process?