| Oracle® Access Manager Upgrade Guide 10g (10.1.4.2.0) Part Number B32416-01 |
|
|
View PDF |
| Oracle® Access Manager Upgrade Guide 10g (10.1.4.2.0) Part Number B32416-01 |
|
|
View PDF |
This chapter is intended for directory server administrators who are responsible for maintaining and updating directory schemas and data. Here you will find information on preparing the environment for the Oracle Access Manager (formerly known as Oblix NetPoint or Oracle COREid) schema and data upgrade. The following topics provide information to help you prepare your environment:
Configuring the Challenge/Response Phrase at the Object Class Level
Configuring Unique Namespaces for Directory Connection Information
Preparing Your Directory Instances for the Schema and Data Upgrade
Halting On-the-fly User Data Migration at First Login Temporarily
Adding An Earlier Identity System to Use as a Master for the In-place Method
Adding an Earlier Access Manager to Use as a Master for the In-Place Method
Finishing Preparation for the In-Place Schema and Data Upgrade
Note:
Unless explicitly stated, the information in this chapter applies equally to both upgrade methods. If your starting Oracle Access Manager release is earlier than 6.1.1, contact Oracle Support before upgrading:
http://www.oracle.com/support/contact.htmlThere are several types of data used by Oracle Access Manager: user data, configuration data, and policy data. User data refers to the enterprise identity store (LDAP) that Oracle Access Manager is configured to work against. Configuration is metadata pertaining to Oracle Access Manager configuration that is stored in directory. Policy data is metadata pertaining to access policies that is stored in the directory.
Zero Downtime Method: The schema upgrade occurs independently. Data upgrades occur when you upgrade the clone of the first installed COREid Server and first installed Access Manager. In discussions about the schema and data upgrade for the in-place method, you can substitute the concept of the "master" Identity Server and Policy Manager with the zero downtime concept of the clone of the first installed Identity Server and Access Manager. See also "Schema and Data Upgrades with the Zero Downtime Upgrade Method".
In-place Method: A schema upgrade occurs when you upgrade the master Identity Server. Configuration data is also upgraded during the master Identity Server (formerly known as the COREid Server) upgrade. When you upgrade additional Identity Server instances, the initial schema and data upgrade is detected automatically. Further Identity System schema and data upgrades are not requested.
Policy data is upgraded with the master Policy Manager (formerly known as the Access Manager component). When the configuration tree and policy node are in the same directory server, the master Identity Server upgrade touches only configuration data. Policy data is upgraded only when the master Policy Manager is upgraded. If you have a large number of entries in the configuration tree, data migration can take a while to complete.
Additional schema updates are not typically required with policy data unless you have several directory instances configured as shown here:
Directory_1 communicates with the Identity System
Directory_2 communicates with the Identity System and Access System
Directory_3 communicates with the Access System
In such cases, the Oracle Access Manager schema and configuration data are upgraded on Directory_1 and Directory_2 during the master Identity Server upgrade. The schema and policy data are upgraded on Directory_2 and Directory_3 during the master Policy Manager upgrade.
Both Methods: No schema upgrade occurs during Access Server, WebPass, or WebGate upgrades. A data upgrade occurs automatically during each Access Server upgrade and a directory server profile is created for each Access Server.
For more information, see:
Oracle recommends that you keep all workflows on one directory server. When workflows are stored on multiple directory servers, you cannot automatically upgrade the schema and data.
If your installation includes workflows on separate directory servers, you must manually upgrade the schema and data. In this case, see Appendix D.
Oracle recommends that you record details about your existing deployment as summarized in Appendix F. Summaries that can help you track the completion of upgrade tasks in your environment are also provided in Appendix F.
Figure 5-1 illustrates the tasks involved in preparing for and performing the schema and data upgrade when you use the in-place upgrade method. Additional information follows the figure. For details about performing a schema and data upgrade when you choose the zero downtime upgrade method, see "Schema and Data Upgrades with the Zero Downtime Upgrade Method".
Figure 5-1 Schema and Data Upgrade Task Overview for In-Place Upgrades
Task overview: Preparing for and performing in-place schema and data upgrades
Review the following topics to gain an understanding of the conditions that might govern the sequence and tasks you must perform:
Prepare Directory Instances and Data: Perform the tasks in the following list to prepare your directory instances and data for the upgrade, as described in:
Perform the next set of tasks to create a master environment of secondary servers for your original master Read/Write directory server instances:
Finish preparing for the schema and data upgrade as described in "Finishing Preparation for the In-Place Schema and Data Upgrade".
Upgrade the schema and data in sequence, as described in:
When the schema and data upgrade is successful, prepare for and upgrade the remaining components as described in Part III.
During data migration, the following two files are created, regardless of your directory server type. Both contain new Oracle Access Manager data, generated after applying the upgrade for the specific incremental release. The older Oracle Access Manager tree is deleted and the appropriate file is uploaded to generate the upgraded tree:
During Identity Server data migration, output_fromversion_to_toversion_osd.ldif is created in the IdentityServer_install_dir\identity\oblix\tools\migration_tools\obmigratedata directory.
During Policy Manager data migration, output_fromversion_to_toversion_psc.ldif file is created in the PolicyManager_install_dir\access\oblix\tools\migration_tools\obmigratedata directory
Additionally, the files listed next are created to log any ldap specific errors as follows:
During Identity Server data migration, error_output_fromversion_to_toversion_osd.ldif file is created in the IdentityServer_install_dir\identity\oblix\tools\migration_tools\obmigratedata directory.
During Policy Manager data migration, error_output_fromversion_to_toversion_psc.ldif file is created in the PolicyManager_install_dir\access\oblix\tools\migration_tools\obmigratedata directory
For more information, see "Accessing Log Files".
This discussion introduces additional tasks that Oracle recommends you perform when upgrading in a replicated environment.
Your deployment can employ the use of replicas to increase system availability and improve performance. Using replicas in a failover configuration helps increase system availability, which is important for enterprise-class applications. Replicas can be used in load-balancing configurations to enhance the performance and throughput of the application.
To help keep down time to a minimum, Oracle recommends that you disable replication until the upgrade is complete and all features have been validated to work correctly. Presuming that the Identity Server, Policy Manager, Access Server, and all plug-ins that might contact the directory are configured properly, disabling replication (with Active Directory, for example) helps Oracle Access Manager remain in service during the upgrade. One set of servers can work with the original directory information (release 7.0.4, for example) while upgrading to 10g (10.1.4.0.1). The 10g (10.1.4.0.1) schema is backward compatible with the release 7.0.4 schema as long as you do not delete Oracle Access Manager attributes from any Oracle Access Manager object classes.
When performing the next tasks, use your directory vendor documentation as a guide unless otherwise indicated. Additional information follows the task overview.
Note:
If you are using the zero downtime upgrade method, you can disable the replication agreement before upgrading the schema and enable it after upgrading the data. For more information, see Part VI.Task overview: Upgrading in a replicated environment
Disable the replication agreement, if possible.
Prepare for and perform the schema and data upgrade as outlined in the previous task overview. If you are using the zero downtime method, see Part VI.
Stop the Identity Server, Policy Manager, and Access Server from the original deployment.
Re-establish the replication agreement.
Push changes to the replicas.
After changes have been pushed to the replicas, then upgrade the components configured against these replicas as described in Part III. If you are using the zero downtime method, see Part VI.
Note:
The upgrade tools automatically detect that the schema and data have been upgraded and these steps are suppressed when upgrading remaining components.For more information, see:
Your deployment can be architected to leverage user data replicas in various ways. For example, to achieve failover or load-balancing and the like, as described in the following discussions:
Suppose that you have one master directory server (named M) and one replica (named R). To setup a failover configuration, you need one DB Profile configured with the primary server named M and a secondary server named R. In this case, Oracle Access Manager will failover to R when M is not reachable.
Upgrade Consideration: This directory server configuration with replica will be a multi-master deployment. Hence, user schema should be uploaded against the master instance M.
This scenario is quite similar to the failover configuration in the preceding discussion. Except that in this situation there are multiple primary LDAP servers to help balance the load. For example, suppose that you have one master directory server (named M) and one replica (named R). To setup a load-balancing configuration, you will create one DB Profile with two primary servers configured. In this case, both server M and R will be configured as primary.
Upgrade Consideration: This is the same consideration as in the failover configuration in the preceding discussion. The directory server configuration with replica will be a multi-master deployment. Therefore, the user schema should be uploaded against the master instance (M).
In this configuration you will have multiple primary servers along with secondary servers configured. Let us consider that you have one master directory server (say M) and two replicas (say R1 and R2). There will be one DB Profile configured with two primary servers as M and R1, and there will be one secondary server, R2.
You can configure the 'Failover threshold' for this DB Profile as 1 to indicate that after one primary server goes down start using secondaries along with remaining primaries.
Upgrade Consideration: This too is the same consideration as in the failover configuration in the preceding discussion. The directory server configuration with replica will be a multi-master deployment. Therefore, the user schema should be uploaded against the master instance (M).
This deployment configuration is typically employed when you have one Read/Write master and one read-only replica. For example, suppose that the Read/Write master is M and the read-only replica is R. In this case, you must configure two DB Profiles for the same namespace. One DB profile will allow only write operations to occur against M. The other DB Profile will allow only read & bind operations against R. Oracle Access Manager will use the appropriate profile based on the requested operation.
Upgrade Consideration: This is not a multi-master deployment of directory servers. During the upgrade, the schema should be upgraded only against the master (M), because the replica (R) is read-only.
Replicated configuration data can be leveraged by Oracle Access Manager in failover configurations. In this scenario there is one master directory server (named M) containing the configuration data and another Read/Write replica (named R). There is one DB Profile configured with primary instance (M) and secondary instance (R).
Note:
Oracle Access Manager does not allow load-balancing for configuration data. The same is true for policy data replication.Upgrade Consideration: This is a multi-master deployment. Schema and data upgrades should be done only against one instance (M). This applies to both Identity System and Access System (policy) data.
If Challenge and Response attributes are configured at the Employees tab level (rather than at the object class level), then the configuration data upgrade might not complete correctly. Oracle recommends that before starting the upgrade you ensure that the Challenge and Response attributes are configured at the object class level.
To configure the challenge/response phrase as the object class level
Login into COREid System Console, as usual.
Navigate to the Common Configuration tab, then click Object Classes in the left pane.
If attributes P and Q are configured as Challenge and Response attributes, then recollect the object class to which P and Q belongs.
On the Configure Object Classes page, click the object class to which the P and Q attributes belong.
On the View Object Class page, click the Modify Attributes button.
In the attribute configuration applet, ensure that when attribute P is selected in the Attributes list, the Challenge semantic type is highlighted in the Semantic Types list.
If the Challenge semantic type is not highlighted, select the Challenge semantic type and save this.
Repeat with attribute R for the Response semantic type.
For more information, see your earlier version of the Oblix NetPoint or Oracle COREid Administration Guide (Volume 1 if you have a two volume set).
Note:
User data is not migrated during the upgrade, but is migrated during the first login following the upgrade. For more information about the implications of this during an in-place upgrade, see "Halting On-the-fly User Data Migration at First Login Temporarily". If you are using the zero downtime method, see "User-Data Migration and Multiple Values in Challenge and Response Attributes for LPM".Each directory server profile contains connection information for a directory that includes the profile name, a domain or namespace to which it applies, a directory type, and a set of operational requirements for Read, Write, Search, and so on. A default directory server profile is created automatically each time you install the Identity Server and specify new directory server connection information.
Before release 6.5, the directory namespaces for policy data and user data had to be unique when the data was stored in two separate directories. During the upgrade to 10g (10.1.4.0.1), you must confirm this uniqueness to ensure that multi-language capability can be enabled.
When your environment includes one of the following situations, you need to perform the following procedure before upgrading to ensure that namespaces are unique and do not overlap with other directory server profile namespaces:
When earlier Oracle Access Manager installation with configuration data or policy data is stored in a different directory server than user data
Note:
Exceptions to overlapping namespaces include a directory server profile for a Microsoft Active Directory subdomain, and the directory server profile containing the configuration DN.If the namespace for the configuration DN or policy base assigned during Identity System setup matches the searchbase and you upgrade without ensuring unique configuration and policy data namespaces, the automated process to enable multi-language capability during the master Identity Server upgrade might fail. In the case of a zero downtime upgrade, this capability is enabled when you upgrade the clone of the first Identity Server.
Using third-party tools is outside the scope of this manual. For more information about how to ensure that the namespace is unique on the directory server, see the documentation for your directory server. For more information about configuring LDAP directory server profiles, see your earlier Oblix NetPoint or Oracle COREid Administration Guide. For details about re-running Identity System, Policy Manager, or Access Server setup, see your earlier Oblix NetPoint or Oracle COREid Administration Guide.
To ensure namespace uniqueness and reconfigure if needed
On the directory server, ensure that the namespace for configuration data is unique and does not overlap any other namespace. .
On the directory server, ensure that the namespace for policy data is unique on the directory server and does not overlap any other namespace.
Using the COREid System Console, configure LDAP Directory Server profiles to include unique namespaces for configuration data and policy data. For example:
COREid System Console, System Admin, System Configuration
Configure Directory Options, Profile_Link
Namespace: Enter a unique namespace
Restart Identity Servers.
Re-run Identity System setup, as described in your earlier Oblix NetPoint or Oracle COREid Administration Guide.
Re-run Policy Manager setup, as described in your earlier Oblix NetPoint or Oracle COREid Administration Guide.
Re-run Access Server setup, as described in your earlier Oblix NetPoint or Oracle COREid Administration Guide.
Before starting an upgrade, Oracle recommends that you perform all tasks outlined in the following overview to prepare your directory instances for the schema and data upgrade.
Task overview: Preparing directory instances for the schema and data upgrade
Review supported directory servers, as follows:
Navigate to MetaLink at https://metalink.oracle.com.
Log in to MetaLink as directed
Click the Certify tab.
Click View Certifications by Product
Select the Application Server option and click Submit.
Choose Oracle Identity Manager and click Submit.
Click Oracle Identity Management Certification Information 10g (10.1.4.0.1) (html) to display the Oracle Identity Management page.
Click the link for Section 6, "Oracle Access Manager Certification" to display the certification matrix.
Directory Release Deprecated: Perform activities in "Preparing a Directory Server When Its Release is Deprecated".
Perform activities in "Changing the Directory Server Search Size Limit Parameter".
Review considerations for your directory server and ensure that your environment meets all requirements as described in:
Back up all directory instances containing Oracle Access Manager data, using instructions from your directory vendor.
Proceed to "Backing Up Existing Oracle Access Manager Data".
If your directory server release is no longer supported, you can upgrade earlier directory server profiles in Oracle Access Manager and the directory server as outlined next, then upgrade to 10g (10.1.4.0.1).
Note:
Use the next overview as a guide and see your vendor documentation for specific details about administering the directory server. See also "Upgrade Strategies When Support is Changed or Deprecated".Task overview: Installing a new directory server when its release is deprecated
Check the latest support information for Oracle Access Manager 10g (10.1.4.0.1), as follows:
Navigate to MetaLink at https://metalink.oracle.com.
Log in to MetaLink as directed
Click the Certify tab.
Click View Certifications by Product
Select the Application Server option and click Submit.
Choose Oracle Identity Manager and click Submit.
Click Oracle Identity Management Certification Information 10g (10.1.4.0.1) (html) to display the Oracle Identity Management page.
Click the link for Section 6, "Oracle Access Manager Certification" to display the certification matrix.
Before starting an upgrade, install a 10g (10.1.4.0.1)-supported directory server using your vendor documentation as a guide.
In your earlier Oracle Access Manager installation, reconfigure directory server profiles (and database instance profiles contained within) before you start the upgrade to 10g (10.1.4.0.1). For details, see your earlier Oblix NetPoint or Oracle COREid Administration Guide (Volume 1 if you have a two volume set).
In your earlier Oracle Access Manager installation, change the directory server as follows:
From the COREid System Console select System Configuration, Configure Directory Server Options, click Directory Server, change any settings as needed.
Re-run Identity System setup, as described in your earlier Oblix NetPoint or Oracle COREid Administration Guide (Volume 1 if you have a two volume set), to ensure that configuration files are properly updated.
Before starting the upgrade, perform all relevant tasks in this chapter. If you are using the in-place upgrade method, add a master Identity Server (formerly known as the COREid Server), WebPass, and Policy Manager (formerly known as the Access Manager component) configured against the new directory. If you are using the zero downtime method, see Part VI.
Upgrade using the method you have chosen as described in this manual.
Before starting the upgrade you need to verify that the value of the directory server's search size limit parameter is greater than the number of entries in your configuration tree. The default value for this parameter varies from directory to directory. See your vendor documentation for complete details.
Note:
If the number of entries in your configuration tree is greater than the value of the directory server's size limit parameter, then the Oracle Access Manager data upgrade process might fail.There are no specific rules to determine a suitable value for this parameter. As a result, the process of defining and verifying the correct value is an iterative one, as described in the next procedure.
To set an appropriate value for the directory server's size limit parameter
Check the suitability of the existing value of the directory server's size limit parameter using the ldapsearch command to retrieve all nodes in your configuration tree to retrieve all entries. For example:
ldapsearch.exe -h host -p port-D bindDN -w password -b config_root -s sub (objectclass=*) Dn
In the preceding command, the bindDN is the one that was specified during your earlier Identity System setup (formerly known as COREid).
If the result of the ldapsearch command is successful, there should be no problem during data migration and you can skip the rest of this procedure.
If the ldapsearch results in a message about exceeding the size limit, complete step 2.
Increment the value of the directory server's size limit parameter using information available in your vendor documentation, then repeat step 1.
For example, try setting the value to 10000 (or a promising value for your environment) then complete another ldapsearch to see if this is successful. If this also exceeds the size limit, you must repeat step 2 until the ldapsearch command executes successfully.
After a successful ldapsearch, retain the successful search size limit value until you finish upgrading.
After a successful upgrade, you can set the size limit parameter to its original value.
If you have Active Directory as a backend directory server, be sure to review the following information and perform any tasks needed for your environment before upgrading:
Before starting the upgrade you need to verify that the value of the search size limit parameter (MaxPageSize) is greater than the number of entries in your configuration tree. The MaxPageSize parameter specifies the maximum number of entries to return in a search operation. The default value for the MaxPageSize parameter is 1000. If the number of entries in your configuration tree is greater than the value set for the MaxPageSize parameter, the Oracle Access Manager data migration process might fail.
Note:
The example shown here is based on Active Directory running on Microsoft Windows 2000 Advanced Server. These details might vary for other versions. See your Active Directory documentation for specific details for your version.To view the existing value of the MaxPageSize parameter and set a new value
Use the ntdsutil tool at the command prompt to display the current value of the MaxPageSize parameter, as shown in the following transcript. For example:
C:\Documents and Settings\Administrator ntdsutil
ntdsutil: ldap policies
ldap policy: connections
server connections: connect to server <machine_name>
Binding to <machine_name> ...
Connected to <machine_name> using credentials of locally logged on userserver connections: q
ldap policy: show values
Use the ntdsutil tool at the command prompt to set a new MaxPageSize value and view the changes, as shown in the following transcript. For example:
C:\Documents and Settings\Administrator ntdsutil ntdsutil: ldap policies ldap policy: connections server connections: connect to server <machine_name> Binding to <machine_name> ... Connected to <machine_name> using credentials of locally logged on userserver connections: q ldap policy: set MaxPageSize to <new_value> ldap policy: commit changes ldap policy: show values
To choose an appropriate value for this parameter, see "Changing the Directory Server Search Size Limit Parameter".
Active Directory, schema modifications can only be completed against a schema master. You can skip this discussion if your earlier environment is configured to use an Active Directory schema master.
If you are not using a schema master, the following procedure can be completed on Windows 2000 platforms. Otherwise, see the Microsoft knowledge base article 285172 "To Enable Schema Updates by Means of the Registry" (previously published under Q285172P) on the Microsoft support Web site.
To enable the schema to be modified
Open your Active Directory schema plug-in, which is often located in Administrative Tools.
Right-click the top node for the schema and select Operations Master to display the Change Schema Master dialog.
Check the box beside "The Schema may be modified on this Domain Controller", then click OK.
Before starting the upgrade you must verify that the value of the size limit parameter is greater than the number of entries in your configuration tree. For details, see "Changing the Directory Server Search Size Limit Parameter".
With ADAM as the directory server, there is no support for obsolete schema cleanup during the upgrade. With ADAM, you must update the schema manually during the upgrade process. However, after manually upgrading the schema, you can accept the automatic data upgrade and complete the component upgrade process.
Support for ADAM started with release 6.5. When upgrading ADAM, Oracle Access Manager provides the following schema files for manual upgrades to configuration and user directories:
Each file contains only the specific schema modifications between the named releases. This means:
If you are upgrading from release 6.5, you must upload the 650_to_700 files during the incremental upgrade from release 6.5 to 7.0. In this case, you must also upload the 700_to_1014 files during the incremental upgrade from release 7.0 to 10g (10.1.4.0.1).
If you are upgrading directly from release 7.0 to 10g (10.1.4.0.1), you need only upload the 700_to_1014 files during the incremental upgrade from 7.0.
Note:
There are no specific files needed during the upgrade when you are using statically-linked auxiliary classes.A sample ldifde command to manually update the ADAM schema is shown here and described in Table 5-1. For more information, see your Microsoft documentation:
ldifde -k -b
"<user_distinguished_name>""<domain_name>""<user_password>"
-c"<GUID>"<ADAM_instance_ID> -i -f ADAM_oblix_schema_add -s
<ADAM_server_name> -t <port>
Table 5-1 ldifde Command Description for ADAM
| Option | Description |
|---|---|
|
-k |
This option ignores errors. |
|
-b "<user_distinguished_name>" "<domain_name>" "<user_password>For example:cn=administrator,o=oblix.com,c=us password |
To extend the schema, the values represent: |
|
-c "<GUID>" <ADAM_instance_ID> |
In this option, "<GUID>" should be retained as is, not replaced by any value; do include the quotes. <ADAM_instance_ID> should be substituted by the ADAM root DSE using tools like ldp.exe. When the initial connection is made, the root DSE is shown. For example, an ADAM root DSE value might be EC31B31B-19FC-4FD4-8590-3BD57D6A3E77. |
|
-i -f <filename> |
The -i option specifies the import option.The -f option identifies a file name; the value identifies the file you are importing. For example: ADAM_oblix_schema_add.ldifADAMAuxSchema.ldif |
|
-s <ADAM_server_name> |
This value is the name of the computer where ADAM is installed. |
|
-t <port > |
This value is the port number on which this instance listens for the schema update (an open port is needed). |
Before starting the upgrade you must verify that the value of the size limit parameter is greater than the number of entries in your configuration tree. For details, see "Changing the Directory Server Search Size Limit Parameter".
During the first Identity Server and Policy Manager upgrade, the user under whom the IBM SecureWay directory server runs must have read and write access to Oracle Access Manager schema files and to the directory containing the schema files. During the upgrade, you might be prompted to copy the schema files. The upgrade program provides instructions on where to copy them.
The next task overview is provided as a guide in the event that the IBM directory server in your earlier installation is not supported in 10g (10.1.4.0.1). Any references to a specific product release is provided for illustration only.
Note:
See your vendor documentation for explicit information about administering your directory server. See also "Upgrade Strategies When Support is Changed or Deprecated".Task overview: Upgrading with an unsupported IBM Directory Server
Check the latest support information for Oracle Access Manager 10g (10.1.4.0.1), as follows:
Navigate to MetaLink at https://metalink.oracle.com.
Log in to MetaLink as directed
Click the Certify tab.
Click View Certifications by Product
Select the Application Server option and click Submit.
Choose Oracle Identity Manager and click Submit.
Click Oracle Identity Management Certification Information 10g (10.1.4.0.1) (html) to display the Oracle Identity Management page.
Click the link for Section 6, "Oracle Access Manager Certification" to display the certification matrix.
Before starting the Oracle Access Manager upgrade, you must upgrade your earlier IBM Directory Server (for example, v4.x) data and schema to IBM Directory Server version 5.1 using information available in your IBM documentation.
Before starting the upgrade to 10g (10.1.4.0.1), complete activities in "Changing the Directory Server Search Size Limit Parameter".
Use 10g (10.1.4.0.1) installation packages to upgrade Oracle Access Manager components as described in this guide.
Before starting the upgrade you must verify that the value of the orclsizelimit parameter is greater than the number of entries in your configuration tree. This specifies the maximum number of entries to return in a search operation. For Oracle Internet Directory the size limit parameter is orclsizelimit. The default value for this parameter is 1000. To choose an appropriate value for this parameter, see "Changing the Directory Server Search Size Limit Parameter".
Note:
The example in the following procedure is based on Oracle Internet Directory version 10.1.2 running on Microsoft Windows 2000 Advanced Server. These details might vary for other versions. See your Oracle Internet Directory documentation for specific details for your version.To view the existing value of the orclsizelimit parameter or set a new value
Open Oracle Directory Manager (ODM).
In the left navigator pane, expand the Oracle Internet Directory Servers.
Select the Directory Server instance to which you have configured your earlier release of Oracle Access Manager.
In this instance page (right pane), select the System Operational Attributes tab.
The "Query Entry Return Limit" parameter on this page refers to the orclsizelimit.
The value in the text box against this Query Entry Return Limit parameter, shows the existing value for the orclsizelimit parameter.
Modify the value in the text box against the Query Entry Return Limit parameter, then apply the changes.
Oracle Access Manager 10g (10.1.4.0.1) does not support Siemens DirX directory. There is no migration path with this directory.
Before starting the upgrade you must verify that the currently directory server release is supported. If not, see "Preparing a Directory Server When Its Release is Deprecated". Also, you need to ensure that the value of the size limit parameter is greater than the number of entries in your configuration tree. On a Sun (formerly iPlanet) directory server is nsslapd-sizelimit (Size Limit). This specifies the maximum number of entries to return in a search operation. The default value for this parameter is 2000. To choose an appropriate value for this parameter, see "Changing the Directory Server Search Size Limit Parameter".
Note:
The example is based on iPlanet 5.1 running on Microsoft Windows 2000 Professional. These details might vary for other versions. See your Sun directory documentation for specific details for your version.To view the existing value of the nsslapd-sizelimit parameter and set a new value
Open the iPlanet console.
In Servers and Applications tab, expand the tree in the left pane to show a list of all existing Directory server instances.
Select the Directory Server instance to which you have configured COREid.
Open the management window of the selected instance.
In the opened window, select the Configuration tab.
Select the Performance tab to display the existing value of this size limit parameter.
Modify the value in the size limit parameter text box, then save the changes.
As discussed in Chapter 2, Oracle recommends that you back up existing data before performing certain upgrade tasks. Figure 5-2 shows the types of data to back up before starting an upgrade, regardless of the method you are using.
For more information about the data that you need to back up, see the following topics in this chapter:
Backing up Oracle Access Manager Configuration and Policy Data
Chapter 8 includes details about:
The upgraded schema offers backward compatibility with the earlier schema, as far back as release 6.1.1. However, you cannot roll back a schema upgrade using any Oracle-provided tools. Some directory server vendors provide tools that you can use to back up the schema. If you back up the earlier schema using external tools before upgrading, you should be able to reinstate the backup copy if you decide to roll back to the original release.
Before starting the upgrade, Oracle recommends that you use tools provided by your directory vendor to backup the schema for your existing directory server instances. For example, Sun ONE directory server stores the schema in the slapd-instance-nameconfig/schema/99user.ldif file.
For more information, see your directory vendor documentation. Not all directory server vendors provide tools to back up the schema.
Before starting the upgrade Oracle recommends that you manually export the Oracle Access Manager configuration and policy data to an ldif file. This file can be used to restore the setup in the unfortunate event of an upgrade failure.
Most vendors provide a directory server console application that can be used to export the directory data into an ldif file. Alternatively you can execute an ldapsearch for the configuration- and policy base at the sub-tree level. In this case, you can use a filter such as (objectclass=*) and re-direct the output of the search to an ldif file.
To back up configuration and policy data
Perform the Ldapsearch command.
In the command, specify the configuration/policy base to back up user and group data.
Ldapsearch –h hostname -p port> D bind_dn -w password -s sub –b config/policy base dn (objectclass=*) > backup_cp_data.ldif
The steps to backup the user and group data are similar to those in "Backing up Oracle Access Manager Configuration and Policy Data". However, in this case, you specify the searchbase.
For components installed on Windows platform, Oracle recommends that you backup the Windows registry entries for the component in addition to the user and group data.
To back up user and group data
Perform the Ldapsearch command.
In the command, specify the searchbase to back up user and group data.
Ldapsearch –h hostname -p port> D bind_dn -w password -s sub –b searchbase dn (objectclass=*) > backup_ug_data.ldif
Windows: Complete activities in "Backing Up Windows Registry Data".
Unless you chose to store workflows separately by configuring appropriate DB Profiles, workflow data is automatically backed up as part of the configuration data. When workflows are stored separately, you must perform similar steps to back up workflow data as you did when "Backing up Oracle Access Manager Configuration and Policy Data".
The only difference when backing up workflow data separately, is that you specify the namespace of the workflow database instance profile in the Ldapsearch command, as shown in the procedure here. For example, if the database instance profile is named workflow_namespace, that is what you include in the command.
For components installed on Windows platform, Oracle recommends that you backup the Windows registry entries for the component in addition to the user and group data.
Perform the Ldapsearch command.
In the command, specify the workflow to back up user and group data.
Ldapsearch –h hostname -p port> D bind_dn -w password -s sub –b workflow_namespace (objectclass=*) > backup_wf_data.ldif
Windows: Complete activities in "Backing Up Windows Registry Data".
To speed up searching for tickets, you also need to archive processed workflow instances, as described next.
Workflow instances, including those that have been completed and processed by the workflow participants, are stored in the directory server. During the upgrade, workflow data is not disturbed or deleted.
Before starting the upgrade, Oracle recommends that you archive all processed workflow instances. Archived instances are stored in an ldif file in IdentityServer_install_dir/identity/oblix/data/common/wfinstance.ldif. This provides a record of the processed workflows and can help speed up the search for workflow tickets.
To archive your processed workflow instances to speed up searching for tickets
Navigate to the COREid System Console, as usual.
From the User Manager, Group Manager, or Organization Manager application, select Requests.
On the Monitor Requests page, fill in the search criteria and search for tickets.
If any results are returned, select these and click the Archive button.
A file is created named wfinstance.ldif and stored in the IdentityServer_install_dir/identity/oblix/data/common directory.
To help with a recovery strategy, Oracle recommends that you back up any directory instances containing Oracle Access Manager data before you start the upgrade.
Use instructions from your directory vendor to accomplish this task. Describing third-party tools is outside the scope of this manual.
User data is not migrated during the upgrade, but is migrated during the first login following the upgrade. You perform the activities in this discussion when performing an in-place upgrade only, after backing up data and before preparing host computers.
Note:
If you are using the zero downtime method, this migration is halted automatically until you start it. For more information, see "User-Data Migration and Multiple Values in Challenge and Response Attributes for LPM".As discussed in Chapter 4, when you upgrade from an earlier release to Oracle Access Manager 10g (10.1.4.0.1), the configuration data stored in the oblix tree of the directory server is migrated automatically and the value of the obVer attribute is changed to 10.1.4.0. However, user data (multiple values in challenge and response attributes for Lost Password Management only) is not migrated until the first login following the upgrade. This means that the obVer attribute value remains less than 10.1.4.0 in user data (in the OblixOrgPerson class).
Unless you temporarily halt the immediate (also known as on-the-fly) user data migration as described in the task overview, the first time a user logs in after the upgrade to 10g (10.1.4.0.1) that user entry is immediately migrated. Any existing challenge and response values for that user are encoded (@1# is appended to the end) and the obVer attribute value for that user is changed to 10.1.4.0 in the OblixOrgPerson class. However the rollback process does not revert these changes. If you rollback to the previous release, the obVer value in the user entry in the OblixOrgPerson class remains 10.1.4.0 and challenge and response values remain encoded format.
Task overview: Halting, then restarting user data migration at first login
Right now, before starting the upgrade, perform activities in the procedure "Halting On-the-fly Migration of User Data: Phase 1"; then finish all other activities in this chapter.
Perform activities in Chapter 6 in sequence to upgrade the Identity System schema and data, then perform steps the procedure "Halting On-the-fly Migration of User Data: Phase 2".
Note:
Phase 2 is a one time activity that must be performed after upgrading the Identity System schema and data and before any administrator or user login, even when you have a joint Identity and Access System deployment.Perform remaining in-place upgrade tasks, as described in Chapters 7 through 13.
Validate your deployment as described in Chapter 14 to ensure that it is operating as expected and that it does not need to be rolled back to the earlier release.
After validating that your upgraded deployment does not need to be rolled back to the earlier release, perform steps in "Restarting On-the-fly User Data Migration for In-place Upgrades".
Phase 1 includes setting the obVer attribute for the Master Administrator entry and then upgrading the schema and data to 10g (10.1.4.0.1). Phase 2 occurs after the schema and data upgrade. In Phase 2, you remove the Challenge and Response semantic types at both the tab level and the object class level.
Before performing the following Phase 1 procedure, there are several conditions to take into account:
If OblixOrgPerson does not exist in the objectclass list of the user entry, then you must first add it as described in step 1. Otherwise, start with step 2.
After performing the last step, the lost password management feature will not work.
After temporarily halting on-the-fly migration of user data at first login, Oracle recommends that you stop processing or performing the following actions to ensure that user data will maintain backward compatibility:
Stop processing workflow tickets: for example, create user, change attributes, and the like.
Stop modifying Challenge and Response attributes from the Modify Profile page.
To temporarily stop the immediate migration of user data (Phase 1)
Add OblixOrgPerson to the Master Administrator's user entry, if needed:
ldapmodify.exe -h <Host> \ -p <Port> -D <Bind DN> -w <Bind Password> \ -f <ldif file containing attribute to be added>
The format of LDIF file to be created when adding OblixOrgPerson to the objectclass list is as follows. This example is for the Netscape Directory Server:
dn: <Administrator DN>
changetype: modify
add: objectclass
objectclass: OblixOrgPerson
Set the obVer attribute for the Master Administrator entry in the LDAP directory server to 7.0.4 using the following command:
ldapmodify.exe -h <Host> \ -p <Port> -D <Bind DN> -w <Bind Password> \ -f <ldif file containing attribute to be modified>
The format of LDIF file to be created is as follows. This example is for the Netscape Directory Server:
dn: <Administrator DN>
changetype: modify
replace: obver
obver: 7.0.4
Finish remaining preparation tasks as described in this chapter.
Perform a schema and data upgrade for your deployment as described in Chapter 6, which includes instructions to perform Phase 2 of this procedure in "Halting On-the-fly Migration of User Data: Phase 2".
For details about restarting user data migration after validating the success of the upgrade for the entire deployment, see "Restarting On-the-fly User Data Migration for In-place Upgrades".
Your next activity is to prepare host computers for the master components you will add and use when upgrading the schema and data. The master components include an earlier Identity Server, WebPass (and Policy Manager (formerly the Access Manager component) if you have the Access System installed).
For details about preparing host computers before installing master components, see the following topics in Chapter 8:
After preparing host computers for the master components, proceed to "Adding An Earlier Identity System to Use as a Master for the In-place Method".
Joint Identity and Access System: If you also have the Access System installed, you perform tasks in "Adding an Earlier Access Manager to Use as a Master for the In-Place Method" after adding the master Identity System. If you do not have the Access System installed, skip Access System-related activities.
Whether your installation includes the Access System or not, you will upgrade the Identity System schema and data after completing activities in this chapter.
You complete activities here to add one (earlier) Identity Server instance (formerly known as the COREid Server) and WebPass to your existing installation. This additional Identity System will be used as a secondary server for your original master Read/Write directory server instances. Upgrading the schema and data against these master components helps ensure that the schema and data upgrade is successful before you upgrade the rest of your earlier installation.
Note:
If you are upgrading while switching from a Solaris platform to Linux, you can skip this step. The Identity System instances that you install on a Linux host will serve as master components. For more information about upgrading while switching from a Solaris platform to Linux, see Appendix B.The master instance that you add here can be installed on any computer you choose that meets 10g (10.1.4.0.1) requirements. However, the master instance that you add need not be configured for things like auditing and access reporting (even if this is configured for other Identity Servers in your environment). The master instance that you add here has a single purpose and that is to be used during the schema and data upgrade. After upgrading your entire Identity System environment, you can retain this additional instance or remove it without impacting the rest of the upgraded environment.
Note:
When your earlier installation includes languages other the English, this additional instance should be installed with the same Language Packs.Setting up master Identity System for the schema and data upgrade is described next.
Task overview: Adding a master Identity System for the schema and data upgrade includes
Defining Additional Instances in the Existing System Console
Setting Up the Master Identity System for the In-place Schema and Data Upgrade
Before you begin, confirm that you have completed tasks in Table 5-2. Failure to complete prerequisites might adversely affect your upgrade.
Table 5-2 Master Identity Server Installation Prerequisites
| Master Identity Server Installation Prerequisites |
|---|
|
Perform all preparation activities in this chapter.
|
|
Review information in the introductory chapters in Part I. |
The Identity Server instance that you will add requires a WebPass. Before you can install either, however, you must define details for the additional instances in the existing COREid System Console. For additional details, see your earlier Oblix NetPoint or Oracle COREid Administration Guide (Volume 1 if you have a two volume set).
Note:
For clarity, this discussion uses earlier terminology that you will see onscreen.To add information for additional components in the System Console
Add information about the new WebPass instance in the COREid System Console. For example:
Navigate to the existing COREid System Console, as usual. For example:
http://hostname:port/identity/oblix/
where hostname refers to computer that hosts the existing WebPass Web server; port refers to the HTTP port number of the existing WebPass Web server instance; and \identity\oblix connects to the COREid System Console.
In the COREid System Console, select System Configuration, then select Configure WebPass and click the Add button.
On the Add a new WebPass page, fill in the following information:
Name: A unique identifier for this WebPass instance (it might include a release number and port number). For example: WebPass_611_6047.
Hostname: The name full DNS name of the computer hosting this WebPass instance. You can install this instance anywhere; there are no caveats.
Port: The port number on which this WebPass instance will listen.
Maximum Connections: The maximum number of connections this WebPass opens to COREid Servers. Set this value to 1 for the COREid Server you will add.
Transport Security: Select the security method used for communications between the Identity Server and its Web clients.
Note:
Transport security between all Identity System components (Identity Servers and WebPass instances) must match: either all open, all Simple mode, or all Cert.Maximum Session Time (Hours): The maximum period of time that a connection between the WebPass and Identity Server can remain open. When the time expires, the connection closes and a new one is opened.
Failover Threshold: The minimum number of connections to Primary COREid Servers.
CoreID Server Timeout Threshold: The period (in seconds) that the WebPass attempts to contact a non-responsive COREid Server before WebPass considers the server unreachable and attempts to contact another. If a value is not specified, it indicates that there is no timeout.
Sleep For (seconds): The interval at which WebPass checks its connection with the COREid Server.
Save the information.
Add details for the additional COREid Server instance in the COREid System Console. For example:
In the COREid System Console, select System Configuration, then select Configure COREid Servers and click the Add button.
On the Add a new COREid Server page, fill in the following information:
Name: A unique identifier for this COREid Server instance (it can include a release number and port number). For example: COREidServer_611_6047.
Hostname: The name full DNS name of the computer hosting this COREid Server instance. You can install this instance anywhere; there are no caveats.
Port: The port number on which this instance will communicate with its Web clients (WebPass).
Transport Security: Select the security method used for communications between the COREid Server and WebPass.
Note:
Transport security between all Identity System components (Identity Servers and WebPass instances) must match: either all open, all Simple mode, or all Cert.Maximum Session Time (Hours): Type the maximum period of time that a connection between the WebPass and Identity Server can remain open. When the time expires, the connection closes and a new one is opened.
Number of Threads: Type the maximum for number of concurrent requests that the Identity Server is allowed.
Save the information.
In the System Console, associate this COREid Server with the WebPass and specify the priority as Secondary. For example:
From the COREid System Console, select System Configuration, then click Configure WebPass.
In the List all WebPasses page, click the link for the WebPass you just defined.
In the Details of WebPass page, click List COREid Servers.
In the page listing Primary and Secondary servers associated with this WebPass, click Add.
From the Select Server list (on the Add a new COREid Server to the WebPass page), click select the server you added a moment ago.
Indicate that this is a Secondary server.
In the Number of connections box, specify the maximum number of connections the WebPass instance opens to this COREid Server (the minimum is 1).
Click Add to associate this COREid Server with the WebPass.
Proceed to "Installing the Master COREid Server Instance", next.
After defining the new instance in the System Console, you must perform this procedure using the earlier COREid Server installer.
During this installation, you must install this instance on the host you specified in the System Console. Also, you must indicate that this is not the first COREid Server for this directory server.
Caution:
During this component installation, do not update the schema or data. For clarity, this discussion uses earlier terminology that you will see on-screen.This procedure provides abbreviated steps to complete this task. For more information, see your earlier Oblix NetPoint or Oracle COREid Installation Guide.
To install an earlier identity Server for the schema and data upgrade
Move earlier installed Identity System Language Packs into the same directory as the earlier COREid Server installer.
Log in as a user with administrator privileges to modify product configuration files, then launch the earlier COREid Server installer, as usual. For example:
Specify a new installation directory for this component.
Languages: Be sure to include and specify all languages that are currently installed in your existing environment.
Choose the same transport security mode for this COREid Server that was specified in the System Console.
Specify configuration parameters for this instance based on the information you added to the COREid System Console. For example:
Name: Enter the unique name for this Identity Server. For example: COREidServer_611_6047.
Hostname: Enter the DNS hostname of the computer where you are installing this instance, as specified in the System Console.
Port: Enter the port number on which this COREid Server communicates with its clients, as specified in the System Console.
Specify directory server details for this instance (to ensure that it is installed as a secondary server for your original master Read/Write directory server instances). For example:
Select No when asked if this is the first COREid Server to be installed for the directory server.
Check the box beside the appropriate communication option (whether SSL-enabled or not) between this COREid Server and the directory server.
Complete the transport security dialog according to the mode you chose earlier.
Select the option that describes your environment. For example, Configuration data will be in the user data directory or whatever is appropriate for your environment.
Select No when asked if you want to update the schema.
Note:
Do not update the schema or data during this installation.Finish the installation as usual.
Start the COREid Server service to confirm that the instance is installed and operating properly.
Proceed to "Installing the Master WebPass", next.
After installing the master COREid Server instance, you now need to install a master WebPass as you defined it in the System Console.
Move earlier installed Identity System Language Packs into the same directory as the earlier WebPass installer, if applicable.
Log in as a user with administrator privileges to modify the product and Web Server configuration files, then launch the earlier WebPass installer.
Dismiss the Welcome screen and respond to the administrator question based upon your platform.
Choose the installation directory. For example:
\OracleAccessManager\Webcomponent
Languages: If asked, choose a Default Locale to use for the Administrator language and any other Locales to install, then continue.
Choose the same transport security mode for the WebPass as you did for the Identity Server.
Enter unique information for this WebPass:
Name: A unique name for this WebPass: WebPass_611_ABC
Hostname: DNS hostname of the COREid Server with which this WebPass should communicate: Identity_DNS_hostname
Port: Port number of the COREid Server with which this WebPass should communicate: Identity_port
Complete the transport security details based on your earlier specification.
Automatically update your Web server configuration file as indicated.
Confirm Web server permissions, as needed.
Establish communication with the Identity Server as follows:
Stop the WebPass Web server instance.
Stop then restart Identity Server service.
Start the WebPass Web server instance.
Proceed to "Setting Up the Master Identity System for the In-place Schema and Data Upgrade".
After installing the additional COREid Server and WebPass, you must now set these up against your original master Read/Write directory server instances.
To set up the master Identity System for the schema and data upgrade
Stop all COREid Server services, if you haven't already.
Start the new COREid Server service only.
Navigate to the COREid System Console, as usual. For example:
Click the Setup button.
Note:
You might be prompted to upload the schema to your LDAP server. However, this is not required because this step has already been done.Specify directory information as follows:
Specify your existing user data directory server type. For example: Sun.
Specify the existing user data directory server details based on your installation. For example:
Directory Server Security Mode—Unsecured or SSL-enabled between the user data directory server and Identity Server
Is Configuration data stored in this directory also?—Yes (default) or No
Note:
If user data is stored separately from configuration data, a similar page appears where you can enter information for the configuration data directory. However, that sequence is not repeated here.On the new page that asks you to specify the location of user and configuration data, enter the configuration bind DN and user data searchbase to be used. For example:
Note:
When setting up the instance as a secondary COREid Server, you are not prompted for Person or Group objectclass details. Instead, after specifying the location of user data and configuration data, the COREid Setup Complete page appears providing a Done button.On the COREid Setup Complete page, click Done.
Create a summary of details for the master Identity Server and WebPass, as described in Appendix F.
Proceed as follows for your environment: If you have an existing Access System in your environment, proceed with
Existing Access System: Complete activities in "Adding an Earlier Access Manager to Use as a Master for the In-Place Method".
Identity System Only: Proceed to Chapter 6 for details about Identity System schema and data upgrades for the in-place upgrade method.
This task must be completed only when your existing installation includes the Access System. You to create a master Access Manager (now known as the Policy Manager) as secondary server for your original master Read/Write directory server instances. This new instance will be used later during the Access System schema and data upgrade.
Note:
If you are upgrading while switching from a Solaris platform to Linux, you can skip this step. The 10g (10.1.4.0.1) Access Manager instance that you install on a Linux host will serve the same purpose. For more information about upgrading while switching from a Solaris platform to Linux, see Appendix B.You will use this master to upgrade the existing Access System schema and data. You do not need to associate and install another Access Server nor a WebGate.
When your original Access Manager component is configured to use SSL-enabled communication with the directory server, the master that you add must also be configured to use SSL-enabled communication with the directory.
In addition to the procedures in this chapter, you can refer to your earlier version of the Oblix NetPoint or Oracle COREid Access Administration Guide (Volume 2 if you have a two volume set).
Task overview: Adding an earlier Access Manager as a master includes
Installing the Master Access Manager for the In-place Schema and Data Upgrade
Setting Up the Master Access Manager for the In-place Method
Note:
If your earlier installation does not include the Access System, you can skip this discussion.Before you begin, confirm that you have completed tasks in Table 5-3. Failure to complete prerequisites might adversely affect your upgrade.
Table 5-3 Master Access Manager Installation Prerequisites
| Master Access Manager Installation Prerequisites |
|---|
|
Perform all preparation activities in this chapter, including "Adding An Earlier Identity System to Use as a Master for the In-place Method", and:
|
|
Review introductory information within chapters in Part I. |
After installing and setting up the master Identity System (formerly known as the COREid System), you can install an earlier Access Manager (now known as the Policy Manager) instance to use as a master for the policy data upgrade.
Again, the steps provided here are abbreviated. For more information, see your earlier Oblix NetPoint or Oracle COREid Installation Guide.
Note:
Do not update the schema and data during this installation.To install an earlier Access Manager for the schema and data upgrade
Move earlier installed Access System Language Packs into the same directory as the earlier Access Manager installer, if applicable.
Log in as a user with administrator privileges to modify product and Web server configuration files, then launch the earlier Access Manager installer.
Dismiss the Welcome screen, and respond to the question about administrator rights based on your platform.
Choose the same installation directory as the WebPass. For example:
\OracleAccessManager\Webcomponent
Languages: If asked about languages, choose a Default Locale to use for the Administrator language and any other Locales (languages) to install, then click Next.
Respond when asked where policy data is stored and specify directory server details for this instance. For example:
Select your directory server type.
Respond to the question about where policy data is stored.
Select No when asked if you want to update the schema.
Note:
Do not update the schema or data during this installation.On a Solaris system, when policy data is stored with other Oracle Access Manager (formerly known as NetPoint or COREid) data you are asked about the communication method for the existing directory server.
On a Windows system, when policy data is stored with other Oracle Access Manager data you are asked about communication with the directory server.
Specify the transport security mode this Policy Manager will use to communicate with the rest of the Access System.
Note:
Transport security between all Access System components must match: either all open, all Simple mode, or all Cert. When your original Access Manager component is configured to use SSL-enabled communication with the directory server you must choose SSL for this master component.Automatically update your Web server configuration file for this instance and specify the path to your Web server configuration file (then apply changes if you are using a Sun Web server).
Stop the Policy Manager Web server instance, stop and restart the Identity Server service, then start the Policy Manager Web server instance.
Finish the installation as usual, verify any Web server permissions, then proceed to "Setting Up the Master Access Manager for the In-place Method".
The earlier Access Manager you just added must be set up to communicate with your original master Read/Write directory server instances. The following procedures guide you as you make the connections that are necessary for this communication.
During setup, specifications are saved whenever you click the Next button. If you leave setup and restart it later, you are returned to the same place.
To start setting up the master Access Manager for the in-place method
Make sure your Web server is running.
Navigate to the Access System Console from your browser by specifying the URL of the WebPass instance that connects to the Policy Manager. For example:
http://hostname:port/access/oblix
where hostname refers to computer that hosts the WebPass Web server; port refers to the HTTP port number of the WebPass Web server instance; and \access\oblix connects to the Access System Console.
You will see the main Access System page.
Click the Access System Console link.
You are informed that the application is not yet set up.
Click the Setup button.
The next page asks about the directory server type.
You need to specify details about the directory servers where user data, configuration data, and policy data are currently stored. You will be asked to provide information about the directory server for each type of data.
To specify directory server details
Select your user data directory server type, then click Next.
Specify the user data directory server details based on your installation, then click Next. For example:
Machine: The user data directory server DNS hostname
Port Number: The user data directory server port number
Root DN: The user data directory server bind DN
Root Password: The password for the bind DN
Note:
For Active Directory, a Domain Name field is included to fill in. With ADSI, a User-Principle-Name field is included where you enter the UserPrincipleName of the Root DN, such as:admin@mycompany.com.Select your configuration data directory server type, then click Next.
Next you are informed that you can store your user data and configuration data either in the same directory or in separate directories and asked to choose a configuration for your deployment.
Choose the item that describes where you user data and configuration data are stored (together or separately), then click Next.
If the data is stored together, you are asked where policy data should be stored. In this case, continue with step 5.
If the data is stored separately, you are asked to specify details for the configuration data directory server before you continue.
Choose the item that describes where your policy data and configuration data are stored (together or separately), then click Next.
If the data is stored together, continue with step 6.
If the data is stored separately, you are asked to specify details for the policy data directory server before you continue.
The Setup Help button appears on the next page, which you can select to obtain additional information during the setup process. You are now asked to specify the location of the configuration DN, searchbase, and policy base.
Note:
The configuration DN, searchbase, and policy base can be at the same level or at different levels of the directory tree. However, when the searchbase and the policy base are in separate directories, they must have unique DNs. That is, the searchbase cannot beo=oblix,<Policy Base> or ou=oblix,<Policy Base> if they are in separate directories. Similarly, the policy base and the configuration DN cannot be same if they are in separate directories.Specify the appropriate information for your installation, then click Next. For example:
This must be the same searchbase you specified during Identity System configuration.
Configuration DN: o=my-company,c=us
This must be the same configuration DN you specified during Identity System configuration.
Policy Base: o=my-company,c=us
This node resides within the policy directory server. If this node does not already exist, create it manually.
You are now asked to specify the Person object class, which must match the one you specified during Identity System setup. For more information, see your preparation summaries and the Oracle Access Manager Installation Guide.
Enter the Person object class name, then click Next.
For example:
Person Object Class: gensiteOrgPerson
At this point, you are prompted to restart your Web server.
Note:
If you are using IIS, be sure to follow additional on-screen instructions. Consider usingnet stop iisadmin and net start w3svc to stop and start IIS. The net commands help to ensure that the Metabase does not become corrupted.Stop and restart your WebPass/Access Manager Web server instances and the related COREid Server instance, then click Next to continue.
Now you are asked to specify the root directory for Oracle Access Manager policy domains.
Oracle recommends that you accept the default value "/" unless you want to restrict the Master Administrator's ability to define and protect policy domains. For more information, see the Oracle Access Manager Access Administration Guide.
Accept the default root directory for policy domains (or specify a new root directory), then click Next. For example:
The next page asks about configuring authentication schemes.
During this Access Manager setup, two authentication schemes are configured automatically. In addition, you can automatically configure a Basic and a Client Certificate authentication scheme based on the configuration information from your user directory.
To configure authentication schemes
Define the same authentication schemes for this Access Manager as you have for others.
Configure the same policies to protect Oracle Access Manager-related (formerly NetPoint or COREid) URLs.
Note:
In this specific case, where you plan to use this Access Manager setup to upgrade the existing Access System schema and data, you do not need to associate and install another Access Server nor a WebGate.You finalize setting up the master Access Manager component as follows.
To finalize the master Access Manager setup
Complete the set up process as described onscreen.
Create a summary of details for the master Access Manager, as described in Appendix F.
Proceed to "Finishing Preparation for the In-Place Schema and Data Upgrade".
The following tasks should be performed on the master instances that you have added to use during the schema and data upgrade. Topics that describe how to prepare components for the upgrade can be found in Chapter 8.
Note:
You perform these activities even if you are upgrading while switching from a Solaris platform to Linux as described in Appendix B.Task overview: Finishing preparation for the in-place schema and data upgrade is explained in following topics
Preparing Release 6.x Environments (if needed)
Preparing Multi-Language Installations (if needed)
Backing Up the Existing Component Installation Directory of master components is described
Backing Up the Existing Web Server Configuration File of master Web components is described
Windows: Backing Up Windows Registry Data of master components is described (if needed)
Stopping Servers and Services is described
Logging in with Appropriate Administrative Rights is described
When you finish all preparation tasks, you are ready to upgrade the Identity System schema and data in place, as described in Chapter 6.
