6 Security Best Practices

6.1.1 Best Practices for HTTPS Use

The following are recommended for using HTTPS with Oracle Application Server:

• Configure Oracle Application Server to fail attempts that use weak encryption. Oracle Application Server can be configured to use only specific encryption ciphers for HTTPS connections. Connections from all old Web browsers that have not upgraded the client-side secure sockets layer (SSL) library to 128-bit can be rejected. This functionality is especially useful for banks and other financial institutions because it provides server-side control of the encryption strength for each connection.

• Use HTTPS to HTTP appliances for accelerating HTTP over SSL. Huge performance overhead of HTTPS forces a trade-off in some situations. Use of HTTPS to HTTP appliances can change throughput from 20 to 30 transactions per second on a 500MHz Unix to 6000 transactions per second for a relatively low cost, making this trade-off decision easier. This is a better solution than mathematics/cryptography cards, which can be added to UNIX/NT/Linux computers.

• Ensure that sequential HTTPS transfers are requested through the same Web server. Expect 40/50 milliseconds CPU time for initiating SSL sessions on a 500 MHz computer. Most of this CPU time is spent in the key exchange logic, where the bulk encryption key is exchanged. Caching the bulk encryption key will significantly reduce CPU overhead on subsequent access, provided that the access is routed to the same Web server.

• Keep secure pages and pages not requiring security on separate servers. While it may be easier to place all pages for an application on one HTTPS server, the resulting performance cost is very high. Reserve your HTTPS server for pages that require SSL. Put pages that do not require SSL on an HTTP server.

  If secure pages are composed of many .GIF, .JPEG, or other files that would be displayed on the same screen, it is probably not worth the effort to segregate secure from non-secure static content. The SSL key exchange (a major consumer of CPU cycles) is likely to be called exactly once in any case, and the overhead of bulk encryption is not that high

6.1.2 Assign Lowest Level Privileges Adequate for the Task

When assigning privileges to module(s), use the lowest levels adequate to perform the module(s) function(s). This is essentially "fault containment" which means if security is compromised, it is contained within a small area of the network and cannot invade the entire intranet.

6.1.3 Best Practices for Cookie Security

Use the following as guidelines for cookies:

• Make sure that cookies have proper expiration dates. Permanent cookies should have relatively short expiration dates of about three months or less. This will avoid cluttering client Web browsers, which may cause errors if the Web browser cannot transmit all the valid cookies. Non-permanent cookies should be set to expire when the relevant application exits.

• Make sure that information in cookies contains Method Authentication. Method Authentication should be used to ensure that cookie data has not been changed since the application set the data. This helps ensure that the cookie cannot be modified and deceive the application. Also, this helps prevent application failures if the cookie is inadvertently corrupted.

• Make sure that the size and varieties of cookies are kept low. There is a finite number and aggregate size of cookies that Web browsers support. If this is exceeded, then the Web browsers will not send all the relevant cookies leading to application failures. Also, very large cookies can result in performance degradation.

• Carefully use cookie domain name facilities. Use of cookie domains should ensure that the domain is the smallest possible. Making the domain oracle.com, for instance, would mean that any host in oracle.com would get the cookie. With hundreds of applications on different parts of oracle.com, a domain of oracle.com for each of them results in attempts to send hundreds of cookies for each HTTP input operation.

6.1.4 Best Practices in Systems Setup

Use the following as guidelines for system setup:

• Apply all relevant security patches. Check MetaLink (http://metalink.oracle.com) and Oracle Technology Network (http://www.oracle.com/technology) for current security alerts. Many of these patches address publicly announced security issues.

• When deploying software, change all default passwords and close accounts used for samples and examples.

• Remove unused services from all hosts. Examples of unused services are FTP, SNMP, NFS, BOOTP, and NEWS. HTTP or WebDAV may be good alternatives.

• Limit the number of people with root and administrative privileges.

• In UNIX, disable the "r" commands if you do not need them. For example, rhost, rcp.

6.1.5 Best Practices for Certificates Use

Use the following guidelines when using certificates:

• Ensure that certificate organization unit plus issuer fields uniquely identify the organization across the Internet. One way to accomplish this would be to include the Dun and Bradstreet or IRS identification as identification for the issuer and the organizational unit within the certificate.

• Ensure that certificate issuer plus distinguished name uniquely identify the user. If the combination of issuer and distinguished name is used as identification, there is no duplication risk.

• Include expiring certificates in tests of applications using certificates. Expiration is an important consideration for a number of reasons. Unlike most username/password-based systems, certificates expire automatically. With longer duration certificates, fewer re-issues are required, but revocation lists become larger.

  In systems where certificates replace traditional usernames/passwords, expiring certificate situations may result in unexpected bugs. Careful consideration of the effects of expiration is required and new policies will have to be developed because most application and infrastructure developers have not worked in systems where authorization might change during transactions.

• Use certificate re-issues to update certificate information. Because certificates expire, infrastructure for updating expired certificates will be required. Take advantage of the re-issue to update organizational unit or other fields. In cases of mergers, acquisitions, or status changes of individual certificate holders, consider re-issuing even when the certificate has not yet expired. But pay attention to key management. If the certificate for a particular person is updated before it expires, for example, put the old certificate on the revocation list.

• Audit certificate revocations. Revocation audit trails can help you reconstruct the past when necessary. An important example is replay of a transaction to ensure the same results on the replay as during the original processing. If the certificate of a transaction participant was revoked between the original and the replay, failures may occur which would not have occurred when the original transaction was processed. For these cases, the audit trail should be viewed to simulated authentication at the time when the transaction was initially processed.

6.1.6 Review Code and Content Against Already Known Attack

It is quite common for viruses or known attacks to resurface in slightly altered shape or form. Thus, just because a threat has been apparently eliminated does not mean it will not resurface. Use the following as guidelines to minimize the recurrence of the threat:

• Ensure that programs are reviewed against double encoding attacks. There area many cases where special characters, such as <, >, | are encoded to prevent cross-site scripting attacks or for other reasons. For example, "<" might be substituted for ">". In a double encoding, the attacker might encode the "&" so that later decoding might involve the inadvertent processing of a >, <, or | character as part of a script. Prevention of this attack, unfortunately, can only be provided by careful program review, although some utilities can be used to filter escape characters that might result in double encoding problems in later processing.

• Ensure that programs are reviewed against buffer overflow for received data.

• Ensure that programs are reviewed against cross-site scripting attacks. This attack typically tricks HTML and XML processing via input from Web browsers (or processes which act like Web browsers) to invoke scripting engines inappropriately. However, it is not limited to the Web technologies, and all code should be evaluated for this.

6.1.7 Follow Common Sense Firewall Practices

The following are some common recommended practices pertaining to firewalls; while not unique to Oracle Application Server, these are important to overall Oracle Application Server security:

• Place servers providing Internet services behind an exterior firewall of the stateful inspection type. Stateful inspection means that the firewall keeps track of various sessions by protocol and ensures that illegal protocol transitions are disallowed through the firewall. This blocks the types of intrusion that exploit illegal protocol transitions.

• Set exterior firewall rules to allow Internet-initiated traffic only through specific IP and PORT addresses where SMTP, POP3, IMAP, or HTTP services are running. Some protocols (for example, IIOP) leave ports open without receiving processes. PORT and IP combinations that are not assigned to running programs should not be permitted.

• Set interior firewall rules to allow messages through to the intranet only if they originate from servers residing on the perimeter network. All incoming messages must first be processed in the perimeter network.

• Send outgoing messages through proxies on the perimeter network.

• Do not store the information of record on bastion hosts. Bastion hosts are fortified servers on the perimeter network. Information and processing should be segmented such that the bastion hosts provide initial protocol server processing and generally do not contain information of a sensitive nature. The database of record and all sensitive processing should reside on the intranet.

• Disallow all traffic types unless specifically allowed. allow only the traffic required by Oracle Application Server for better security. For example, HTTP, AJP, OCI, LDAP.

6.1.8 Leverage Declarative Security

Oracle HTTP Server has several features that provide security to an application without requiring the application to be modified. These should be leveraged and/or evaluated before programming similar functionality as those features into the application. Specifically:

• Authentication: Oracle HTTP Server can authenticate users and pass the authenticated user-id to an application in a standard manner. It also supports single sign-on, thus reusing existing login mechanisms.

• Authorization: Oracle HTTP Server has directives that can allow access to your application only if the end user is authenticated and authorized. Again, no code change is required.

• Encryption: Oracle HTTP Server can provide transparent SSL communication to end customers without any code change on the application.

These three features should be leveraged heavily before designing any application specific security mechanisms.

6.1.9 Use Switched Connections in DMZ

Oracle recommends that all DMZ attached devices be connected by switched, not bussed connections. Furthermore, devices such as the Cisco 11000 series devices, which can provide IP, port, and protocol rules between each pair of connected devices are preferred.

6.1.10 Place Application Server in the DMZ

Application servers should exist in the DMZ. In this architecture Oracle Application Server Web Cache only forwards requests to computers containing Web servers. Web servers only forward requests to application servers or via PL/SQL to database servers. The application servers only forward inward requests to the database or, perhaps, special message processing processors in the intranet. This provides excellent fault containment because a compromised Web server must somehow compromise an application server before the database can be attacked.

6.1.11 Secure Sockets Layer

SSL encryption can be used to secure both LDAP and HTTP traffic that passes between the various components of the Oracle Application Server. To ensure that all LDAP queries being sent to Oracle Internet Directory are SSL-encrypted, you need to configure your Oracle Internet Directory instance to run with a configuration set that supports only SSL-encrypted LDAP connections. The default mode installed with Oracle Application Server allows a given Oracle Internet Directory instance to be configured to listen on both SSL and non-SSL ports. Refer to the Oracle Internet Directory Administrator's Guide for more details on configuring Oracle Internet Directory instances with SSL.

SSL encryption is unrelated to the installation or use of HTTPS, which allows users to access Oracle Application Server components over HTTP while using SSL to encrypt Web client packets."

6.1.12 Tune the SSL SessionCacheTimeout Directive

The Apache server in Oracle Application Server caches a client SSL session information by default. With session caching, only the first connection to the server incurs high latency.

In a simple test to connect and disconnect to an SSL-enabled server, the elapsed time for 5 connections was approximately 11.4 seconds without SSL session caching as opposed to approximately 1.9 seconds when session caching was enabled.

The default SSLSessionCacheTimeout is 300 seconds. Note that the duration of a SSL session is unrelated to the use of HTTP persistent connections. You can change the SSLSessionCacheTimeout directive in httpd.conf file to meet your application needs.

6.1.13 Plan Out Final Topology Before Installing Security Components

Consult the Oracle Application Server Enterprise Deployment Guide and the Oracle Identity Management Concepts and Deployment Planning Guide documents when planning out the final target topology. Identify the steps in installing and configuring the various Oracle Application Server components consistent with the options of the Oracle Universal Installer, rather than approaching the desired topology on an ad-hoc basis.

6.3.1 Avoid Writing Custom User Managers

The OC4J container continues to provide several methods and levels of extending security providers. The UserManager class can be extended to build a custom user manager that allows you to leverage the functionality provided by the JAAS Provider. Both Oracle Application Server Single Sign-On and Oracle Internet Directory provide APIs to integrate with external authentication servers and directories respectively, thus allowing developers more time to focus on actual business logic instead of infrastructure code.

6.3.2 Authentication Mechanism with the JAAS Provider

OC4J allows different authentication options for J2EE applications. Oracle recommends leveraging the OracleAS Single Sign-On server whenever possible for the following reasons:

• It is the default mechanism for most Oracle Application Server components such as OracleAS Portal and OracleAS Wireless.

• It is easy to set up in a declarative fashion and does not require any custom programming.

• It provides a seamless way for PKI integration.

For environments where OracleAS Single Sign-On is not available, and custom authentication is required, one should use JAAS compliant LoginModules to extend OC4J authentication. When using LoginModules, it is important to only use application relevant principals (roles) associated with the authenticated subject to preserve least privilege.

6.3.3 Use Fine-Grained Access Control

Unlike the coarse-grained J2EE authorization model as it exists today, the JAAS Provider integrated with OC4J allows any protected resource to be modeled using Java permissions. The Java permission model (and associated Permission class) is extensible and allows a flexible way to define fine-grained access control.

For example, a servlet can be written with Subject.doAs or Subject.doPrivileged to control code that executes sensitive operations.

6.3.4 Use Oracle Internet Directory as the Central Repository

Although the JAAS Provider supports a flat-file XML-based repository useful for development and testing environments, it should be configured to use Oracle Internet Directory for production environments. Oracle Internet Directory provides LDAP standard features for modeling administrative metadata and is built on the Oracle database platform inheriting all of the database properties of scalability, reliability, manageability, and performance. To optimize performance, adjust the caching configurations appropriate for your environment.

6.3.5 Develop Appropriate Logout Functionality for J2EE Applications

Simple J2EE applications using HTTP Basic authentication do not support the concept of logout, relying instead on the user to close the Web browser. When using other forms of authentication, including OracleAS Single Sign-On, it is important to plan out various logout and timeout flows. OC4J has an adjustable HTTP session inactivity parameter that is set to 20 minutes by default. If J2EE applications are leveraging OracleAS Single Sign-On and want to support full logout functionality, they should be written with the appropriate logout dynamic directives.

6.4.1 Configure for High Availability

Single sign-on failure is catastrophic since it means no single sign-on protected application can be accessed. Two recommendations for high availability of OracleAS Single Sign-On are:

• Carefully consider inclusion of any other types of processing on the single sign-on servers since this can make instability more likely.

• Consider deploying multiple single sign-on servers fronted by load balancing hardware to protect against failures in single sign-on listeners. In this case, the address of the load balancer is used as the single sign-on address and the single sign-on listener configuration information is replicated. It is also recommended that the database be a RAC configured for additional improvements in availability. Configuration details for multiple single sign-on servers can be found at Oracle Technology Network (http://www.oracle.com/technology).

6.4.2 Leverage Oracle Application Server Single Sign-On

OracleAS Single Sign-On should be used as the primary point of security. This is a benefit administratively and a major convenience to application customers. Also, OracleAS Single Sign-On is well integrated with the rest of Oracle Application Server Infrastructure and can, via Oracle Internet Directory and other means, be integrated with non-Oracle application and infrastructure. Also, as single sign-on becomes a single point for authentication, opportunities to attack the multiple authentication entities of sites today are reduced.

OracleAS Single Sign-On single authenticated user for all applications allows better control for more uniform authorization.

6.4.3 Use an Enterprise-Wide Directory in Place

In order to deploy an effective single sign-on solution, the user population must be centralized in a directory, preferably an LDAP-based directory such as Oracle Internet Directory. Having users represented in multiple systems (for example, in multiple Microsoft Windows NT domains) makes setting up the infrastructure for a common identity more difficult. In addition, clearly defining and automating the user provisioning process makes managing the single sign-on environment much easier.

6.4.4 Use OracleAS Single Sign-On Instead of Writing Custom Authentication Logic

OracleAS Single Sign-On provides the infrastructure to validate credentials and allows for various different authentication mechanisms such as username, password, X.509 certificates. Moreover, since these can be shared across different applications and Web sites, end users do not have to create a new username, password for each different corporate application.

6.4.5 Always Use SSL with Oracle Application Server

The OracleAS Single Sign-On server simplifies user interaction by providing a mechanism to have a single username and password that can be used by multiple partner applications. However, with this ease of use, comes the caution that the single sign-on server should always be accessed in the correct fashion; a breach of the common password can now put all partner applications at risk. Hence, the single sign-on server should always be configured to allow connections in SSL mode only. This protects the end user's credentials going across the wire. Applications where security and data confidentiality is important should also be protected by SSL. From a performance perspective, use of SSL hardware accelerators is recommended.

6.4.6 Username and Password Only on Login Screen

The OracleAS Single Sign-On server provides a standard login screen. This login page is serviced from the single sign-on server, which typically is installed on a different computer from the one the end user is trying to access. Thus, it is critical that before the end user enters their login and password, that a valid single sign-on screen is observed. This prevents users from unknowingly providing their username or password to inappropriate servers.

6.4.7 Log Out So Cookies Do Not Remain Active

Most users do not log out of Internet applications and this creates problems at two levels:

1. A security risk. Another person accessing the work station can now reuse the cookie. Also, since the session remains valid until it times out, a hacker from another machine has a longer time window to guess the session id/cookie value.

2. The system resources on the server associated with the cookie are not released until the session is ended or invalidated.

For application developers and administrators, single sign-on session duration and inactivity timeouts should be configured appropriately (for example, one hour inactivity timeouts for sensitive applications).

OracleAS Single Sign-On is unable to logout users for external applications. Therefore, closing all Web browser windows is important.

6.5.1 Use bulkload.sh Utility

The bulkload.sh utility checks standard LDIF formatted files for schema violations and duplicates, and generates SQL*Loader intermediate files for fast loading into the database tables underlying Oracle Internet Directory. Use the bulkload.sh utility whenever there is an initial bootstrap required. For example, when setting up synchronization with Microsoft Active Directory or other LDAP directory servers.

Oracle recommends passing the LDIF file output from third-party LDAP directories into bulkload.sh -check mode, which will alert you to any problems with your existing LDAP schema.

Most third-party LDAP directories (including Oracle Internet Directory) support output to LDIF without any operational attributes (which typically cannot be loaded into another vendor's directory). If you are loading data into Oracle Internet Directory from another directory which does not support this, you will have to manually remove any operational attributes prior to sending the LDIF file to bulkload.sh -generate mode.

If your input LDIF file is from another Oracle Internet Directory instance, then you must use the -restore option to bulkload.sh to preserve these operational attributes as is during the bulkload.

For more information on the bulkload.sh utility refer to the Oracle Internet Directory Administrator's Guide.

6.5.2 Replicate for High Availability

Oracle Internet Directory supports both multimaster and fan out styles of directory replication. Refer to the Oracle Identity Management Concepts and Deployment Planning Guide for guidelines.

For high availability, consider placing an Oracle Internet Directory multimaster replication group behind a network load balancer to provide a single IP address to your LDAP client applications. If a replicated node becomes unavailable, the load balancer can be configured to re-route requests automatically to an available server.

Additionally, each Oracle Internet Directory node can run on Oracle Application Server RAC, further improving availability through increased database uptime and data availability. Other high availability solutions deployable with Oracle Internet Directory are listed in the Oracle Identity Management Concepts and Deployment Planning Guide.

6.5.3 Use SSL Binding

SSL is considered the Internet standard protocol for highly secure transportation of data. In addition to the strong PKI authentication using digital certificates, SSL also provides multiple data integrity and data encryption layers to protect your communication channels. SSL provides multiple cipher suites with varieties of encryption algorithms for many security levels.

Oracle Internet Directory supports three SSL authentication modes:

1. Confidentiality mode (no-authentication mode)

   In this mode, SSL cipher suites use the Diffie-Hellman algorithm to generate a session key for client or server at run time. The session key will be used to encrypt the communication channel. No server or user SSL wallet is necessary. In this mode, the channel will be encrypted using a Diffie-Hellman key.

2. Server Authentication only mode

   This mode essentially uses certificates for authentication. The client needs to verify the server certificate. This mode is most commonly used in the Internet environment since any client that needs to communicate with aa SSL server does not require a certificate. A client can use their user and password identification to authenticate itself to the server. The username and password are protected by SSL encryption when being transferred on the wire.

3. Server and Client Authentication mode (Mutual authentication)

   In this mode, both client and server use RSA certificates to authenticate each other. First, the client authenticates the server by validating its certificate. In return, the server also requires the client to send its certificate to prove its authenticity.

In addition to choosing an authentication mode, you should choose appropriate security algorithms. For more information refer to the Oracle Internet Directory Administrator's Guide

6.5.4 Use Backup and Restore Utilities

Depending on your Oracle Application Server enterprise topology, you may want to consider backing up Oracle Internet Directory as part of backing up your entire application server environment. For more information, refer to the Oracle Application Server Administrator's Guide and the Oracle Internet Directory Administrator's Guide before deciding on an overall backup and recovery strategy for all of your Oracle Identity Management Infrastructure components.

6.5.5 Monitoring and Auditing Oracle Internet Directory

You can monitor and audit Oracle Internet Directory in one of three ways:

1. The Oracle Enterprise Manager LDAP page provides a very simple way to monitor the LDAP service and determine if it is up and running under its associated load.

2. You can also check the log files of various LDAP processes to ensure there are no errors showing up.

3. LDAP audit log service provides more granular information such as security violation information or sensitive events. The audit log can be further customized to specific directory operations and events.

Oracle recommends that you perform, at the very least, a weekly review of the audit and error logs. System administrators can do a more regular review via Oracle Enterprise Manager to provide better availability.

6.5.6 Assign Oracle Internet Directory Privileges

While it is possible to install Oracle Application Server as an Oracle Internet Directory super user, Oracle recommends that this not be done as it imparts more privileges than required.

To install Oracle Application Server, a user needs to be a member and owner of the Oracle Application Server Administrator's group.

When installing Oracle Application Server, the directory administrator should add the installation user as a member and owner of the Administrator's group. The administrator should then remove the member as the owner once the installation has completed.

6.5.7 Change Access Control Policies

Oracle Internet Directory administrators should change the default access control policies to better control user administration as required.

Oracle Internet Directory administrators should adjust the default access control and password policies using Oracle Directory Manager, in accordance with specific administrative policies for directory access and passwords. This includes both value and state parameters. Refer to the Oracle Internet Directory Administrator's Guide for specific parameters affecting both Access Control and Password Policies."

6.5.8 Best Practice for Directory Integration Platform

This section includes the following topics:

• Use Identity Management Realms

• Configuring DIP Synchronization Service

• Oracle HR Synchronization

6.5.9 Recommendations for Migrating Oracle9iAS Applications to an Existing Oracle Internet Directory

Oracle Application Server 10g installs an Identity Management infrastructure (including Oracle Internet Directory) as part of each Standard or Enterprise Edition install. However, some organizations may need to delay the upgrade of their Identity Management Infrastructure (Oracle Internet Directory, OracleAS Single Sign-On, DAS, DIP, OCA) and thus need to upgrade mid-tier components from Oracle9iAS to Oracle Application Server 10g while maintaining an existing Oracle Internet Directory installation from previous versions of Oracle9iAS or Oracle9i DB. In this case, the following points need to be considered:

• Before starting the upgrade process, the user keys in the older repository must be made consistent with the keys used to identify users in Oracle Internet Directory. This will enable the upgrade process to correlate the private keys with those present in the production Oracle Internet Directory system.

• The upgrade process will install its own local infrastructure (including a local Oracle Internet Directory instance) against which the Oracle Application Server 10g mid-tier component(s) you are installing can be validated before switching to the previously deployed instance of Oracle Internet Directory.

• Once the upgrade is completed, the upgraded component should be verified for correctness against the newly installed, local Oracle Internet Directory instance.

• Once the verification is complete, simply redirect applications from using the new, local Oracle Internet Directory to using the production Oracle Internet Directory.

As with the upgrade case, the presence of a corporate directory in a deployment influences the process by which the deployment can roll out new services against existing Identity Management infrastructure. In case the existing corporate directory is replicated, some special steps need to be taken by administrators to create a test replica of the production Oracle Internet Directory. Then, install and verify the components against the test replica before switching to the production Oracle Internet Directory service. Refer to the Oracle Application Server Administrator's Guide for more information.

6.5.10 Configuration of the Self-Service Console

Rather than creating users and assigning them to groups as separate steps, consider incorporating the group assignment step during user creation. To do this:

1. Log in to the Oracle Internet Directory Self-Service Console as a DAS privileged user (orcladmin or designate).

2. Select the Configuration tab.

3. Select User Entry > Add Role.

4. Search for and select any commonly-subscribed group entries.

Now whenever you or any other DAS privileged user performs a Create User sequence, the list of specified groups will appear in the next-to-last step, in a section called Roles Assignment. Simply click whichever checkboxes are relevant to the newly-created user, and that user will automatically be made a member of all the groups you specify.

6.5.11 Use opmnctl instead of oidmon and oidctl

In Oracle Application Server, you no longer need to run oidmon and oidctl to start and stop Oracle Internet Directory processes. OPMN stores the proper sequences and controls these services. Refer to the Oracle Process Manager and Notification Server Administrator's Guide for more information.

6.5.12 Configure Active Directory Synchronization

Prior to configuring Windows Native Authentication, be sure to first configure the Active Directory DIP Connector and bootstrapped the appropriate cn=users and cn=groups containers within your desired Oracle Identity Management Realm. Do not configure the External Authentication Plug-in for Active Directory if your goal is to enable Windows Native Authentication

6.5.13 Use User Attributes and Password Hints for Resets

Users who forget their OracleAS Single Sign-On passwords can reset them on their own by using the Oracle Internet Directory Self-Service Console. You must authenticate yourself in one of the following ways:

• If, while previously changing their password, a user specified a password hint question, then the Confirm Additional Personal Information window will ask them for the correct answer to the reminder question when attempting a password reset.

• Users who have not previously set a password hint will be presented with the Confirm Additional Personal Information window, which prompts them for other personal data as configured the Oracle Delegated Administration Services administrator, via the Password Reset Validation field in the Add New Attributes Window of the User Management section of the Self-Service Console.

Refer to the Oracle Internet Directory Administrator's Guide for more information.