5 Post-Installation Security Configurations

This chapter discusses additional security configurations that you should perform immediately after installing JD Edwards EnterpriseOne, as well as the initial security setup for administration applications, tables, and other EnterpriseOne tools. It contains the following topics:

5.1 Change Default EnterpriseOne User Passwords

Following an installation, EnterpriseOne creates default EnterpriseOne user IDs and passwords. You must immediately change the default passwords or disable the user accounts. See Chapter 9, "Setting Up User Sign-in Security" for more information.

5.2 Change Default Database Installation Passwords

Following an installation, the application database instance might contain default, open schema accounts with default passwords. These accounts and corresponding passwords are well-known, and they should be changed, especially for a database used in a production environment.

See your DBA or the administration guide for your database for help with changing default database passwords.

5.3 Change Default EnterpriseOne System User Passwords for the Database

The EnterpriseOne installation process creates various database users with a default password ("Same as User"). When setting up sign-in security for EnterpriseOne users, each user sign-in record must be associated with a database user, also referred to as a system user, to access the database.

You should change these database user passwords after a successful installation or upgrade. After changing a database user's password, you might have to modify configuration files for the Deployment Server and EnterpriseOne Security Server (also known as the Enterprise Server) because these servers use information from the configuration files to connect to the database. See Appendix D, "Default Database User Accounts" in this guide for a list of default database user accounts for JD Edwards EnterpriseOne 9.1.

For instructions on how to update the passwords in the configuration file settings on the Deployment Server and Enterprise Server, see "Working with Database Security" in the JD Edwards EnterpriseOne Applications Installation or Upgrade guide for your platform and database:

http://docs.oracle.com/cd/E24902_01/index.htm

5.4 Set Up an Independent Security Environment

Set up a separate environment to design and test security before deploying it to the production environment. When testing, start with the least privileges and add more rights as required.

5.5 Applying Security to JD Edwards EnterpriseOne Tools Administration Applications

This section discusses the administration applications, reports, and tables for which you must set up security to limit access to only administrators. It contains the following topics:

You use the EnterpriseOne Security Workbench (P00950) to set up security for the applications, reports, and tables mentioned in this section.

5.5.1 Limit Access to EnterpriseOne Tools Administration Applications and Reports

Use application security in Security Workbench to allow only CNC administrators access, at a minimum, to the following applications and reports:

  • Applications under the System Administration Tools menu.

  • Applications under the Package and Deployment Tools menu.

  • Applications under the System Installation Tools menu.

You can also obtain a list of all JD Edwards EnterpriseOne Tools-related applications by searching in Object Management Workbench (OMW) for H9* system code.

See Managing Application Security in this guide.

5.5.2 Limit Access to JD Edwards EnterpriseOne Administration Tables

Use row security in Security Workbench to allow only CNC administrators the ability to insert and modify data, at a minimum, from these system administration tables:

Table Description Table Name
Security Workbench F00950
Sign-on security F98OWSEC
System user security F98OWPU
OCM F986101
Data Source Master F98611
OMW User Roles F98220
User Profile F0092
User Preferences F00921
User-Role Relationship F95921
Security History F9813

See Managing Row Security in this guide.

5.5.3 Limit Access to Real-Time Events (RTE) Administration Applications

Use application security in Security Workbench to limit access to the following EnterpriseOne applications to administrators only:

  • P90701A (Interoperability Event Definition)

  • P90702A (Interoperability Event Subscription)

  • R90706 (Convert Event Subscriptions) to create Queue Entries

5.5.4 Limit Access to Design Tools and Universal Table Browser

Use Security Workbench to set up external call security to limit access to Windows-based design tools: FDA.exe, TDA.exe, RDA.exe, and UTBrowse.exe. See Managing External Calls Security in this guide.

5.5.5 Limit Access to Data Browser

Use Security Workbench to set up Data Browser security to limit access to the Data Browser application as this can be used to easily access sensitive data from different data sources. See Managing Data Browser Security in this guide.

5.5.6 Limit Access to the User Security Application

Use Security Workbench to set up processing option security to limit access to the User Security application (P98OWSEC). EnterpriseOne password policies are managed as processing options for P98OWSEC. See Managing Processing Option and Data Selection Security in this guide.

5.5.7 Set Up Column Security on Work with Submitted Jobs

Use Security Workbench to set up column security on the User field of the Submitted Job Search form (W986110BA). When you set up this security, only the user that is logged in and submitted the batch job can view the records in the grid that are a result of the batch job. The user cannot see batch jobs submitted by other users and more importantly, the output from those batch jobs. See Managing Column Security in this guide.

5.6 Set Up Object Management Workbench (OMW) Security

Administrators should configure roles and allowed actions for an EnterpriseOne developer.

Refer to Part VI, "EnterpriseOne Developer Security" in this guide for more information on setting up security for OMW users.

5.7 Set Up User Sign-In Policies

If you are managing user IDs and passwords in an EnterpriseOne database, Oracle recommends that you set up the following sign-in policies:

  • Set up the Password Change Frequency value in the User Security (P98OWSEC) application to ensure that users frequently change their passwords.

  • Select the "Force change password for user" option when creating a new user account so that the system will prompt the user to change the password on the next sign-in.

  • Limit the number of invalid password attempts (usually three) before a user account is disabled.

See Chapter 9, "Setting Up User Sign-in Security" in this guide for more information.

You can set processing options for the User Security (P98OWSEC) application to set up default sign-in policies. Refer to Setting Processing Options for P98OWSEC in this guide for more information on setting up password policies.

5.8 Enable Auditing of Security Operation

Set the history setting to 1 under the [SECURITY] section of the JDE.INI file on the security server. This setting turns on the auditing for user login and logoff actions. Use the Security History form exit from the Work with User Security application (P98OWSEC) to review this history or audit records regularly according to your organization's security policy.

See Section 9.3, "Reviewing User Sign-in Security History" in this guide for more information.

5.9 Security Considerations When Using LDAP to Manage Users

If LDAP authentication is enabled in EnterpriseOne, you should securely configure LDAP access from the EnterpriseOne security server by using LDAP over SSL (LDAPS). Refer to Using LDAP Over SSL in this guide for more information.

5.9.1 Assign Role with Least Privilege for _LDAPDEFLT User

If LDAP authentication is enabled and user-role relationships are being managed in EnterpriseOne, you must set up a default role relationship for the _LDAPDEFLT user. All new users who are synchronized from LDAP to the EnterpriseOne database will be assigned the default user-role relationship. It is recommended that you assign a default role to _LDAPDEFLT user that has least privilege. An administrator can assign or remove other roles using the EnterpriseOne Role Relationships application (P95921) at a later time. See Modifying the LDAP Default User Profile Settings in this guide for more information.

5.10 Set Up Single Sign-on Node

Change the default node password for _GLOBALNODE even when you are not using single sign-on from Collaborative Portal or Oracle Portal. It is recommended that you set up a unique single sign-on node with a trusted relationship if you are using multiple security servers on different machines in your environment. Refer to Chapter 11, "Setting Up JD Edwards EnterpriseOne Single Sign-On" in this guide for more information on setting up single sign-on nodes.

5.11 Support of Longer User Names and Passwords

EnterpriseOne does not support more than 10 characters in a user name or password for sign-on. If you want to use more than 10 characters for a user name or password due to compliance issues for web users, you should use one of the following options:

  • Oracle single sign-on or Collaborative Portal single sign-on with EnterpriseOne.

    In this solution, Oracle single sign-on server or Collaborative Portal is responsible for authenticating a longer user name and password. EnterpriseOne uses the single sign-on token to validate the user. You can configure the EnterpriseOne security server to use the same LDAP Server used by the single sign-on server. User mappings from longer user names to EnterpriseOne user names can be provided in LDAP Server. However, in this case, EnterpriseOne non-web users (such as Windows client and Java Connector users) will not be able to log in with more than 10 character user names and passwords. See Chapter 11, "Setting Up JD Edwards EnterpriseOne Single Sign-On" for more information.

  • Oracle Access Manager single sign-on with EnterpriseOne.

    Using Oracle Access Manager, you can manage long user IDs and passwords in a single sign-on configuration with EnterpriseOne. This configuration does not change the behavior of existing EnterpriseOne user IDs, but it requires mapping EnterpriseOne users to the long IDs. See Chapter 12, "Setting Up JD Edwards EnterpriseOne Single Sign-On Through Oracle Access Manager 11g Release 1" for more information.