10 Tips for Protecting your APPS Password

E-Business Suite security is a huge topic, as there are many different facets to consider. This article will consider a small but essential part of the security model: protecting your APPS user password.

The APPS user in the E-Business Suite is the master of its world. I have gathered together some thoughts on steps you can take and things to consider to help you protect your APPS password from being compromised:

  1. Stay current with our latest Security Best Practices

    Regularly review the latest version of Best Practices for Securing Oracle E-Business Suite (Note 189367.1). This note is regularly updated and will give security advice covering many different aspects of Applications 11i.    For Release 12, see Best Practices For Securing Oracle E-Business Suite Release 12  (Note 403537.1)

  2. Regularly change your APPS password

    This is an essential activity from a security perspective and needs to be part of your routine operating procedures. Same applies for other schema passwords and SYSADMIN user. As an aside, don't use predicable passwords, or have a system to create passwords, such as using "0ct0ber" for the password in October as this will make it easier to guess

  3. Always change passwords as part of a clone process from PROD

    It is recomended to change ALL schema passwords and ALL eBiz user passwords in a cloned instance.   You can use Removing Credentials from a Cloned EBS Production Database (Note 419475.1) to achieve this.    Similarly, you don't want to have any relation in the passwords used for PROD compared to any other instances. Data masking and obfuscation is a large topic in its own right, but is also something you may need to consider doing for the cloned instance to protect sensitive data generally. With Release 12, EM plugin provides some data scrambling facilities.

  4. Perform data masking on any files sent to outside parties from the PROD system

    When you need to send any log files or configuration files, ensure that you scan for any sensitive data before packing the files to be sent. In this article we are concerned about the APPS password, but this applies equally well for other data as well. For example, a crude mechanism would be to use "ed" or "sed" on all files to globally change any occurrences of the APPS password before creating a tar archive to email or upload. You may be uploading files to Oracle Support, or just emailing them within your Organization. Whenever the files are going to someone who cannot access them directly you should always check the files before sending.

  5. Create separate schemas with minimal access required for direct database access  

    If anyone requires direct access to the E-Business Suite database, ensure that you create a new unique schema with the specific permissions required for them to perform their job role. Except for a very few Apps DBAs, there should be no reason that anyone else needs the APPS user password. Sometimes pressures of work make it easier to just give someone APPS access, but this should be resisted and the time taken to provide only the minimum access absolutely required. Every person should also have their own unique login (but this is digressing into a separate area that I'll address in a later article).   When considering permissions to allocate, don't be tempted to give read only access to everything, as being able to read sensitive information may be just as damaging as being able to change it.

  6. Protect Apps 11i middle tier file system files

    These days, there is little need to give anyone UNIX-level access to the servers, but it is still important to ensure the "applmgr" operating system user password is well protected. Also consider whether any of your own startup scripts or monitoring scripts have the APPS password hard coded in them, and protect these scripts with chmod 700 permissions, or remove them if no longer needed

  7. Ensure no processes are running with APPS username/password in command line

    Generally the APPS password is not listed in "ps" output, but there may be some manual scripts or other processes intermittently running with the APPS password in clear text or trivially encoded. Ensure these scripts are changed to hide the APPS password. In addition, ensure operating system access is restricted to only those who really need it

  8. Protect OID access

    If you have integrated the E-Business Suite with Oracle Application Server 10g, Single Sign-On, and Oracle Internet Directory, then the Apps user password is stored in the OID database, as it is required for Provisioning to function. The OID administrator and anyone with ldapsearch rights in the Provisioning Profiles will be able to extract the APPS password from OID. This in turn implies the "AppsDN" OID password should be protected in the same way as the APPS password itself.    For assistance in security hardening OID, refer to the Oracle Internet Directory Administrator's Guide 10g ( - Part III Directory Security

  9. Encrypt SQLNET traffic from Middle Tier to RDBMS

    In a previous article, Steven highlighted that ANO is certified with the E-Business Suite. Use encryption to protect the APPS password from network sniffers tracing SQLNET connection packets and deciphering the APPS password on the wire.

  10. Allow only specific IP addresses to access RDBMS via SQLNET

    Slightly off topic, but if someone has acquired the APPS password they still have to be able to gain access to a tool that can use it. Restricting the IP addresses that can access your Apps database will help minimise this risk. If you are still using "fat" clients (Discoverer or ADI for example) then you will have to weigh up the risks against the administrative overhead. Oracle recommends upgrading to server-based equivalent tools or shared desktop technologies such as Citrix so desktop clients no longer need direct access.  This topic is discussed further in E-Business Suite Recommended Set Up for Client/Server Products (Note 277535.1)


Defence in depth is generally considered the best approach so hopefully these recommendations will give you some food for thought when you are reviewing how well your own system is protected.

Sound password policies are critical to enforce access policies and enforce individual accountability.  You need to jealously guard your passwords, particularly for the APPS user.



Excellent article. If you don't mind, we'd like to point to this in our next newsletter.

The only one that gives me pause is the ANO recommendation (#9). The last time I checked ANO was not cheap from a licensing standpoint and cost-prohibitive in a multi-tier environment.

I have a story about the Apps password on the command line - the client said they knew about it but it would be too hard to change all of the custom code and interfaces so they renamed the "ps" command. "top" still worked... :-)


Posted by John Stouffer on July 24, 2007 at 09:26 AM PDT #

Thanks John, go ahead and refer to in your newsletter. I was only consider the technical options rather than any implementation costs in the article of course :-)

Posted by Mike Shaw on July 24, 2007 at 06:48 PM PDT #

The metalink note "Removing Credentials from a Cloned EBS Production Database" (Note 419475.1) is so hot of the press that is has not actually been released yet. Should be available to view in a couple of days.

Posted by Mike Shaw on July 24, 2007 at 06:51 PM PDT #

Regarding "Ensure no processes are running with APPS username/password in command line", if you apply a large patch, the initial FNDLOAD where adpatch loads the patch ldt data exposes the apps password sometimes for more than 20-30 minutes.

Posted by Michael Taylor on July 25, 2007 at 08:42 AM PDT #

Just about to make the same comment as Michael Taylor. Some standard Oracle programs show the apps password on the command line. Not only FNDLOAD but also CONCSUB and numerous other admin scripts show the password to everyone.
So Oracle, you've got a job to do to enhance the EBS security!

Posted by Rik Van Wassenhove on July 27, 2007 at 02:14 AM PDT #

Michael,Thanks.  I've passed this on to our security specialists for their analysis.  I'll post updates on this as soon as possible.Regards,Steven

Posted by Steven Chan on July 27, 2007 at 02:28 AM PDT #

Thanks.  I've passed this on to our security specialists for their analysis.  I'll post updates on this as soon as possible.


Posted by Steven Chan on July 27, 2007 at 02:28 AM PDT #

Mike, Steven
A couple of other things worth mention are

1. Ensure that log files that are generated from application, concurrent manager and database traces, web server are secure. When diagnostics are enabled or logging level on the application server is set at a higher level, applications spit out critical information which should not fall into wrong hands. Companies should have a define log archiving/purging policy. You might have covered it in 6 but I thought it was worth a separate mention.

Posted by Subraya Mallya on August 07, 2007 at 06:42 AM PDT #

Thanks for the tip, Subraya.  Glad to see that you're still in the game, too.Regards,Steven 

Posted by Steven Chan on August 08, 2007 at 01:49 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed


« July 2016