| Oracle® Access Manager Access Administration Guide 10g (10.1.4.3) Part Number E12488-01 |
|
|
View PDF |
| Oracle® Access Manager Access Administration Guide 10g (10.1.4.3) Part Number E12488-01 |
|
|
View PDF |
This chapter discusses several additional Access System configuration and management functions available within the Access System Console. Topics include:
For more information about managing the Access System, see:
Oracle Access Manager should be installed and set up, as described in the Oracle Access Manager Installation Guide. Read the Oracle Access Manager Introduction, which provides an overview of Oracle Access Manager not found in other manuals. Also, familiarize yourself with the Oracle Access Manager Identity and Common Administration Guide, which provides a brief review of Access System applications and installation; introduces Access System configuration and administration; and includes common functions, configuration, and administration.
Earlier chapters in this manual describe configuring administrators and viewing server settings through the Access System Console, System Configuration functions. That information is not repeated here.
The rest of this section discusses the following topics:
Numerous functions are available in the Access System Console, Access System Configuration tab, as shown in the following list. Unless indicated, other chapters in this manual describe Access System Configuration functions:
Access Server Clusters: View existing Access Server Clusters, add new and modify existing Access Server Clusters, configure and delete Access Server Clusters.
AccessGate Configuration: View existing AccessGates, add new and modify existing AccessGates, configure and delete AccessGates.
Access Server Configuration: View existing Access Servers, add new and modify existing Access Servers, configure cache and audit settings.
Authentication Management: Configure Authentication Rules.
Authorization Management: Configure Authorization Rules.
User Access Configuration: List revoked users, flush the user cache, as described in this chapter under "Configuring User Access" .
Common Information Configuration: Generate a cryptographic key to encrypt cookies (covered here), configure a master auditing rule, manage resource type definitions, flush the Password Policy Cache (covered here), handle duplicate action headers. For more information on items covered here, see:
Host Identifiers: Configure host identifiers.
There are several options available in the Access System Console to perform system management operations, which are described in this chapter:
Diagnostics: Show Access Server details, including connection information, as described in "Running Diagnostics".
Manage Reports: Create, view, modify, and execute User Access Privilege Reports, as described in "Managing User Access Privilege Reports".
Manage Sync Records: Archive or purge Sync Records, as described in "Managing Sync Records".
See Also:
"Detecting and Restoring Corrupted Sync Records in Environments with Multiple Directory Servers" for details about using a command-line tool for detecting and recovering from sync record corruption when you have multiple Access Servers writing to multiple Directory ServersFor information about diagnostics, auditing, reports, and logging, see the Oracle Access Manager Identity and Common Administration Guide.
You use the User Access Configuration function available through the Access System Console, Access System Configuration tab, to manage revoked users and flush user data from the cache. This section covers the following topics:
Note:
You must be a Master Access Administrator or a Delegated Access Administrator with appropriate permissions to configure user access.For more information on caches, see Flushing Password Policy Caches and "Automatic Access System Cache Flush". See also the Oracle Access Manager Deployment Guide.
You can create and modify a list of users who are prohibited from accessing any of your resources. This list supersedes any other policies controlling user access to your resources. Once a user has been revoked, if the user tries to refresh the browser, or go to another protected resource, they are denied access. If a revoked user tries to log in, he or she is presented with the following error:
The user corresponding to the credentials (userid=xxxxxxxx password=(omitted) Resource=/access/oblix RequesterIP= nn.nn.nnn.nn HostTarget=http://hostname:port Operation=GET) used in the login has been revoked by an administrator of the Access System.
To create the revoked user list
In the Access System Console, click Access System Configuration, then click User Access Configuration.
The User Access Configuration screen appears.
Click Revoked Users.
The Modify User Revocation List screen appears, displaying the names of revoked users. If no revoked users exist, the Configure User Revocation List screen appears. If any exist, their names appear beneath the Revoked Users link.
Click Select User, then use the Selector feature (Select User button) to add or remove revoked users.
See the Oracle Access Manager Identity and Common Administration Guide for instructions on using the Selector.
Click Save to save your changes (or click Cancel to exit without saving.
You must be a Master Access Administrator to flush user data from the cache.
Flushing the user cache serves to automatically update changes in user access rights. In this case, information about selected users is removed from AccessGate and Access Server caches. For example, you might want to flush a user's information after that user's rights to view or modify an attribute have changed. This is useful when a user needs immediate access to resources.
See the Oracle Access Manager Identity and Common Administration Guide for instructions on using the Selector.
To flush user information from the cache
From the Access System Console, click Access System Configuration, select User Access Configuration, then click Flush User Cache.
The Flush all cached information for specified users page appears.
Perform the following steps to identify individuals and add them to a list of users whose information will be flushed from all caches.
Select the criteria for your search from the first two lists. For example:
Full Name
That Contains
Fill in the empty field to narrow the list of named that will be returned, and then click Go. For example:
sch
In the resulting list of names, click the Add button beside each name to be included in the cache flush operation.
The names of people that you have selected and added appear on the right side of the page.
Repeat steps a through c to finish building your list.
Click Done when you have the list that you want.
The Flush all cached information for specified users page returns with the list of selected names.
Click the Flush Cache button (or click Cancel to terminate the operation).
You are prompted to confirm your decision. If you click OK the names are cleared from the page, and information about these users is flushed from AccessGate and Access Server caches.
Click OK to clear these names (or Cancel to terminate without clearing).
You use the Shared Secret function available through the Access System Configuration, Common Information Configuration tab, to generate a key that encrypts single sign-on cookies sent from an AccessGate to a browser.
Note:
You must be a Master Access Administrator to create a shared secret key. You should generate a cryptographic key as soon as possible after installing Oracle Access Manager, otherwise a less secure default is used.AES is a new encryption scheme introduced in Oracle Access Manager 7.0. If you have a new installation of Oracle Access Manager 10.1.4, AES is the default encryption scheme. RC6 encryption is deprecated in Oracle Access Manager 10.1.4, and its support will be removed in future releases.
If you have upgraded to Oracle Access Manager 10.1.4 from an older version, the older encryption scheme will be retained. Older WebGates may co-exist with newer WebGates as described in the Oracle Access Manager Upgrade Guide:
Use RC4 as the encryption scheme if you have version 5.x and version 7.x WebGates co-existing together.
Use RC6 as the encryption scheme if you have version 6.x and version 7.x WebGates co-existing together.
Use AES encryption only when all the WebGates and Access Servers are upgraded to Oracle Access Manager version 7.0 and higher
Note:
If the shared secret is generated more frequently than the session timeout, then the user may have a cookie that was encrypted using a shared secret that is more than two generations old. In this case, the cookie is rejected and the user is forced to re-authenticate.To generate a cryptographic key
In the Access System Console, click Access System Configuration, click Common Information Configuration.
The Common Information Configuration screen appears.
Click the Shared Secret tab at the top of the screen.
The Generate shared secret screen appears.
Click Modify.
The Generate shared secret page now includes various ciphers from which to choose.
Select the appropriate cipher option for the shared secret (Oracle recommends using the AES cipher).
Click Generate Secret only once.
Oracle Access Manager generates a new cryptographic key and distributes it to each Access Server on your system. The new key replaces the existing key without disrupting service to end users. Re-authentication only happens when the session times out. This process is called grandfathering. Clicking Generate Secret multiple times can put the shared secret key in Identity out of synch with the key in the Policy Manager.
A message informs you the operation was successful.
If you change the shared secret during a user session, the user does not need to re-authenticate. If a cookie is being decrypted with the old shared secret and the cookie is refreshed, it is encrypted with the new shared secret.
If the shared secret is changed more frequently than one-fourth the setting of the idle session timeout parameter, users may have to re-authenticate during a session. Otherwise, user are not required to re-authenticate during a session if the shared secret is changed.
You use the Flush Password Policy Cache function (Access System Configuration tab, Common Information Configuration), to flush all password policies from the Access Server cache. Flushing the password policy cache removes existing password policies and adds newly configured policies.
Flushing the password policy cache serves to automatically update the password policy cached in the Access Server by removing existing password policies and adding newly configured policies. This is useful when you change the password policy from the Identity System and want the changes to be reflected when the Access Server evaluates password policies.
From the Flush Password Policy Cache tab you can also flush all redirect URLs used for password policy enforcement if you have configured redirect URLs. Flushing the redirect URLs serves to automatically update the password policy management redirect URLs whenever they are updated in the Identity System. For the Access System to recognize these changes, the administrator must flush the cache.
You can also flush all cached information for the specified lost password management policy. After clicking the Flush Password Policy Cache tab, a section labeled Flush all cached information for specified lost password management policy is available. A list enables you to choose the lost password policy to be flushed from the cache. If there are none, this is stated on the page. This is useful when you change the lost password policy from the Identity System and want the changes to be reflected when the Access Server evaluates password policies.
Note:
You must be a Master Access Administrator to flush password policy caches. You can also automatically update this cache. For more information about updates to the Access Server cache, see the Oracle Access Manager Identity and Common Administration Guide.To flush password policy caches and redirect URLs
Click Access System Console, click the Access System Configuration tab, select Common Information Configuration, then click the Flush Password Policy Cache tab.
Flush all cached information for specified password policy: Perform the following steps.
From the list under the label (Flush all cached information for specified password policy), select the name of the policy that you want to flush from the cache.
Click the Flush Cache button.
Click OK to confirm your decision
Flush all redirect URLs used for password policy enforcement: Click the Flush Redirect URL button.
Flush all cached information for specified lost password management policy: Perform the following steps.
From the list under the label (flush all cached information for specified password policy, select the name of the policy that you want to flush from the cache.
Click the Flush Cache button.
Click OK to confirm your decision.
You use the Diagnostics item on the Access System Console, System Management page to run diagnostics on all the Access Servers in your Oracle Access Manager system or selected servers.
To run diagnostics for Access Servers
From the Access System Console, select System Management, then click Diagnostics.
You are asked to select the Access Servers on which you would like to run diagnostics
Select the option you want:
All Access Servers: Select All Access Servers, then click the Go button.
Specific Access: Servers Hold down the Control key, then click the names of the servers whose details you want, then click the Go button.
You use the Manage Reports function on the Access System Console, System Management page to manage user access privilege reports.
Each Access Server can collect audit information about the resource requests it handles. The list of existing reports is visible from the Manage Reports page. In addition, you can perform the following operations:
For more information on auditing and reports, see the Oracle Access Manager Identity and Common Administration Guide.
You can create user access privilege reports that verify whether specific users have access to specific resources at specific times. Explanations to help you complete these fields appear in the following procedure.
To add a user access privilege report
From the Access System Console, select System Management, then click Manage Reports.
On the Manage User Access Privilege Reports page, click the Add button.
Complete the information as follows:
Report Name: Choose a self-explanatory name for the audit report.
Description: If you wish, you may describe the report.
Access Server: Name of the Access Server that will collect the information for the report.
Results Storage: Indicate whether the audit data should go to a disk file or a database.
Store in File: Check the box beside this option, then specify the fully-qualified path and file name in the Name of File field.
Store in Database: See the Oracle Access Manager Identity and Common Administration Guide for specific Oracle Access Manager configuration details and the Oracle Access Manager Installation Guide for information on database support.
List of Resources: Click the Add button beside this option to display the Add Resource Rule page, as shown in the following screen shot.
Note:
You may add multiple resources to a report. Access information on each resource will be returned in the report.On the Add Resource Rule page, complete the rule by specifying the following, then click Save to return to the Add New Report page:
URL: The URL of a target resource you want to add to the report.
Resource Type: Supported choices are HTTP and EJB.
Resource Operation: Check boxes appear beside operations you can include in the report. Oracle Access Manager will determine which are permitted against the specified resources, for the specified users, at the specified time.
On the Add New Report page, continue specifying the following information:
From this IP Address: Optional. The IP address of the computer hosting the client browser whose access you want to test. This parameter is optional.
Date/Time of Access: Select a button to determine when a specific resource will be available to the users specified by the current report:
Any: Oracle Access Manager will determine if there is at least some point in time when the resource is available.
Specific date and time: Indicates you want to identify a specific point in time so that Oracle Access Manager can determine if access is permitted at that particular moment.
Check Access for the following users: Specify whether to check the access for all users in the directory or only those you designate.
selected users: Enables you to use the Selector page to locate and add specific users. Choose selected users, click the Select User button, specify your search criteria, then add specific users.
all users: Indicates you want to check the access of all users in the directory.
Click Save on the Add Reports page to save the specifications for the report and display the name you specified as a link on the Manage User Access Privilege Reports page.
From the Manage User Access Privilege Reports page (Access System Console, select System Management, then click Manage Reports), you can perform several operations:
Add: Create a new report as described in "Adding a Report".
Delete: Check the box beside the report name on the Manage User Access Privilege Reports page, then click the Delete button to remove the report. Confirm that you want to delete the report when asked.
Note:
To delete or execute multiple reports simultaneously, check all the boxes on which to operate, then click the appropriate button.Execute: Check the box beside the report name on the Manage User Access Privilege Reports page, then click the Execute button. Confirm that you want to execute the report when asked.
Refresh: Update the list of reports on the Manage User Access Privilege Reports page by clicking the Refresh button.
Modify: Click a link on the Manage User Access Privilege Reports page to display the Manage Existing Report page, then change the parameters for the existing static audit report. See "Adding a Report" for details about each option.
This section includes the following topics:
An Oracle Access Manager deployment can include multiple instances of the Identity Server, Access Server, and Policy Manager. Changes to a user profile or policy information can be made using the Identity System Console or Policy Manager. Configuration changes for Access Servers are made using the Access System Console. All changes are written to the directory server and must be propagated across all components to ensure an integrated and unified view throughout the system to ensure behavioral consistency.
Each change to a user profile or policy information or configuration details results in the generation of a corresponding global synchronization record (sync record). The sync record is stored in the directory server so that it can be shared between all components.
Following is an example of a global sync record for a policy:
obSyncRequestNo=<GSN>, cn=PSCMgmt,obapp=PSC,o=Oblix,<config tree>
Here, GSN refers to the global sync number that is used by the Access Server to track changes to policy information or user information, and to synchronize these changes with data in the directory server and update the directory server with the same information for all instances in the deployment.
A user profile sync record looks like the following example, which is similar to the sync record for a policy except that the cn is different:
obSyncRequestNo=<GSN>, cn=UserMgmt,obapp=PSC,o=Oblix,<config tree>
A change to a user profile in the Identity System Console, involves one Identity Server. The resulting user related sync record would look like the following example:
Dn: obSyncRequestNo=14,cn=UserMgmt,obapp=PSC,o=Oblix,o=company,c=us
1> obSyncRequestNo: 2;
1> obCompID: 20080526T17521689728;
1> obSyncChangeType: 2;
1> obSyncRequestType: 3;
1> obSyncTime: 1211804638;
2> objectClass: top; oblixSyncRecord;
1> obver: 10.1.4.0;
Each line of the sync record provides different information about the change. Included are the sync request number (obSyncRequestNo); the component from which this sync request came (obCompID); the type of change (ObSyncChangeType refers to whether this is an addition, update, or delete); the request type value (obSyncRequestType); the time of the change (obSyncTime); the object class (objectClass: top; oblixSyncRecord); and the version of the Oracle Access Manager release (obver: 10.1.4.0). The policy identifier (obCompSDID); is not observed in a user-related sync record. For more information about these attributes and values, see the Oracle Access Manager Schema Description.
Over time, sync records accumulate. You can manage the space these records consume on the directory server by periodically archiving, or purging, all the records prior to a specified date.
Note:
With Active Directory, modification of the user profile can be monitored with a value ofUserMgmtNodeEnabled (False) in the Access Server Sever globalparams.xml file. For more information, see "Cache Flush Issues with Active Directory".For additional information, see:
You must be a Master Access Administrator to archive sync records.
When you archive sync records, information is stored in an ldif file. The file is typically named nnn.ldif, where nnn is a string of numbers in the GSN sync records format: syncrecordsxxxxxxxxxx.YYYYMMDD.HHMMSS. This format assigns a unique sync record number. xxxxxxxxxxx is a unique number assigned by the system. The time is Universal Time Coordinated (UTC) time. The following file was created July 29, 2008. The cut off time is represented in hours:minutes:seconds (04:08:44), based on a 24-hour clock.
syncrecords1090998000.20080729.040844.ldif
The name represents a unique identifier, as well as the moment at which the file was created and the cut-off time for archiving or purging records. All records created prior to the cut-off time that you select will be archived or purged.
By default, the archived ldif file is stored in:
PolicyManager_install_dir\access\oblix\data\common
where PolicyManager_install_dir represents the directory where you installed the Policy Manager.
During this task, you will select a month, day, and year from lists provided. All records created prior to the date that you select will be archived.When you choose to archive sync records, the location where the ldif file containing the records is stored will be presented in a message for you to record. For example:
Successfully archived 210 sync records generated before the selected date to file /export/home/COREid1014/webcomponent/access/oblix/data/common/syncrecords109099 8000.20080729.040844.ldif
Later on, you could review an archived (also known as an exported) .ldif file if needed. There is no need to import these sync records.
From the Access System Console, click System Management.
In the left navigation pane, click Manage Sync Records.
On the Manage Sync Records page, choose a month, day, and year from the lists provided to specify the date of sync records generated.
Click the Archive Sync Records button.
When asked if you really want to archive the records, click OK to execute the action (or Cancel to revoke the operation).
Record the location when it is presented in a message. For example:
/export/home/COREid1014/webcomponent/access/oblix/data/common/syncrecords109099 8000.20080729.040844.ldif
You must be a Master Access Administrator to purge sync records.
During this task, you will select a month, day, and year from lists provided. All records created prior to the date that you select will be purged. Purged records are deleted.
Note:
Oracle recommends that you archive sync records before you purge them. Later on, you could review an archived (also known as an exported) .ldif file if needed. There is no need to import these sync records.From the Access System Console, click System Management.
In the left navigation pane, click Manage Sync Records.
On the Manage Sync Records page, choose a month, day, and year from the lists provided to specify the date of sync records generated.
Click the Purge Sync Records button.
When asked if you really want to purge the records, click OK to execute the action (or Cancel to revoke the operation).
If your environment does not include multiple Access Servers writing to multiple directory servers, you can skip this section. This section provides the following topics and tasks:
About Cache Flush and Sync Records with Multiple Directory Servers
Blocking Updates from the Policy Manager and Applications using AMAPI
Oracle Access Manager stores three types of information in the directory server:
User data, which can be distributed across multiple directory server instances
Configuration data, which cannot be distributed across multiple directory server instances
Note:
You might have replication configured wherein two master directory servers include the same configuration information, which is described later in this topic.Policy data, which cannot be distributed across multiple directory server instances
Any modification to a user profile or policy information is updated in the directory server. These modifications require an Access Server cache flush to ensure that authentication and authorization information is up to date. Enabling the Update Cache feature in Oracle Access Manager forces a cache flush every time an entry is written to the directory server. If you do not select Update Cache, the Access Server caches are updated when they time out and read new information from the directory server.
Whenever a cache flush request is received by the Access Server (every time an entry is written to the directory server when the Update Cache feature is turned on or on time out and read operations if the Update Cache feature is off), the Access Server:
Fetches the latest oblixGSN entry in which GSN is maintained from the directory server (purging sync records does not impact this).
Checks the oblixGSN objectclass, which is used in the cache flush mechanism
Checks the global sequence number (a value in the obSeqNo attribute within the oblixGSN objectclass) that represents the last flush request number
Increments the global sequence number (obSeqNo value) and stores it in the sync record (oblixSynchRecord)
Updates the sync record with cache flush information, including obSyncRequestNo, ObSyncChangedType, and obSyncTime
See Also:
"About Sync Records"For a successful cache flush operation, the sync record in the directory server must be unique, obSeqNo must have a single unique value, and the oblixGSN objectclass should have a single obSeqNo. For example:
obSeqNo=15,cn=obapp=PSC,o=Oblix,<config tree>
GSN information is stored in the configuration data in a single directory server instance. GSN information refers to the entry for the oblixGSN objectclass, which contains the global sequence number (obSeqNo) value.
Note:
If you have replication configured for a high availability environment, you might have two master directory server instances containing the same configuration information. In such cases, the Access Server updates information in the directory server and the directory servers periodically synchronize their contents with each other.When you have multiple Access Servers writing to multiple directory servers, you will have a sync record for a particular entry or change within each directory server. Both the sync record (oblixSynchRecord) and global sequence number (obSeqNo) should be the same. However, these records can get out of sync due to the time lag between directory server synchronizations.
A corrupted entry might have multiple obSeqNo values or multiple entries under a single obapp=PSC,o=oblix,<config tree> node. For example:
obSeqNo=101,obSeqNo=102,obapp=PSC,o=Oblix,<config tree>
or
obSeqNo=101,obapp=PSC,o=Oblix,<config tree>
obSeqNo=102,obapp=PSC,o=Oblix,<config tree>
When corruption occurs, you will see inconsistent performance between Access Servers. Therefore, you need a way to detect the problem and recover. Recovery requires removal of corrupted entries from the directory server.
Oracle Access Manager enables you to detect sync record corruption in the directory server and recover from it using a new command-line tool. For more information, see "About Detection and Recovery".
A command-line tool named recovergsncorruption that you can use for detection and recovery from sync record corruption is provided and stored in the following path:
PolicyManager_install_dir\access\oblix\tools\recovergsncorruption\
All parameters that are needed during the recovery process can be included as arguments from the command line or can be provided through a script. If you do not provide parameters as arguments on the command line, you will be prompted for the values one by one.
Table 8-1 recovergsncorruption Parameters and Values
| Parameter | Value | Description |
|---|---|---|
|
-i |
PolicyManager_install_dir |
Provides the installation path for the recovergsncorruption utility |
|
-isCacheFlushDisabled |
yes |
Provides your confirmation that you have performed prerequisite tasks in the following topics to prepare for recovery. Use this when you want to perform recovery. Prerequisites include: |
|
-recoverCorruption |
no |
Launches corruption detection without recovery, as follows:
|
|
-recoverCorruption |
yes Note: Before recovery, you must perform preparation tasks to ensure that cache flush operations are halted. See Also: isCacheFlushDisabled Yes |
Launches corruption detection and recovery, as follows:
|
You can also write a script that uses this tool. The syntax in the script will be similar to that when you are running the utility from the command-line. For example:
To detect corruption:
recovergsncorruption -i PolicyManager_install_dir -isCacheFlushDisabled yes
-recoverCorruption no
To detect and recovery from corruption:
recovergsncorruption -i PolicyManager_install_dir -isCacheFlushDisabled yes
-recoverCorruption yes
In either case, before recovery you must ensure that cache flush operations are halted to prevent any possible problems during recovery when sync records are updated.
See Also:
During recovery, the following processes are performed using the original sync records in the directory server.
Process overview: Recovery processing
Duplicate obSeqNo values in a single oblixGSN entry are removed from the directory server (oblixGSN entry will have a single unique ObSeqNo value)
Duplicate entries for the oblixGSN objectclass are removed from the directory server
Sync records that contains the deleted obSeqNo are updated with a new obSeqNo value
obSeqNo is updated: After updating the sync records, obSeqNo is updated with the largest ObSyncRequestNo in the oblixGSN entry
Progress is logged in a file named recovergsncorruption.log in PolicyManager_install_dir\access\oblix\tools\recovergsncorruption\recovergsncorruption.log
If recovery is successful, you are notified. In this case, there will be no duplicate entries for the oblixGSN objectclass in the directory server. The oblixGSN objectclass will have a single unique ObSeqNo value; duplicate values are removed and ObSeqNo is updated (incremented). There are no duplicate sync records. Sync records containing deleted values are removed. For more information, see "Recovering from Sync Record Corruption".
If recovery is not successful, you need to perform steps to revert to the earlier status of the directory server (before recovery was attempted. For more information, see "Correcting Errors that Occurred During the Recovery Process".
Task overview: Detecting and restoring corrupted sync records with multiple directory servers
Review the following topics:
About Cache Flush and Sync Records with Multiple Directory Servers
The rest of this task overview
Detection: Perform tasks in "Detecting Sync Record Corruption".
Recovery: Perform tasks as described in the following topics:
You perform this task when Access Server behavior is inconsistent. You must be a Master Access Administrator to perform this task.
The command is entered on a single line without breaks. The example in this procedure appears to be entered on multiple lines due to formatting constraints for the book.
To detect sync record corruption
From the computer hosting the Policy Manager, locate the recovergsncorruption command-line tool in the following path:
PolicyManager_install_dir\access\oblix\tools\recovergsncorruption\
Start the detection process by providing the following command-line arguments:
recovergsncorruption -i PolicyManager_install_dir -isCacheFlushDisabled yes
-recoverCorruption no
Alternatively, you can run the tool from the command line with no options and let the tool prompt you for the parameter values. For example, recovergsncorruption prompts you as follows:
Please enter the Policy Manager installation directory:
Identity and Policy cache flush disabled? [yes|no]:
Do you want recovery if GSN corruption is detected? [yes|no]:
Review the resulting message to determine how to proceed:
No Sync Record Corruption was Detected: You are finished.
Sync Record Corruption was Detected: Proceed to "Disabling Access Server Cache Flush and GSN Updates"
You perform this task after detecting or recovering from GSN corruption. The log file is created for your reference. It contains information related to the corruption detection or the corruption recovery process; information related to the archived .ldif file; details related to detection or recovery operation success or failure. Also, if the recovery operation fails, the reason for the failure is identified.
The log file is named as described in "About Detection and Recovery" contains the following information:
Each time the recovergsncorruption command-line tool is run, log messages are appended to existing information in the log file. You can delete the log file at any time.
The log file contains the name of generated .ldif file that can be imported later, if desired. A typical log file might look like the following example:
############################# Starting #############################.
Writing Sync records in:
D:/install_dir/access/oblix/data/common/GSNsyncrecords20080630.121814.ldif
Successfully ported the sync records
No corruption was detected under: obapp=PSC,o=Oblix,o=company,c=us
Recovery of policy Sync records completed successfully
Corruption was detected under: cn=UserMgmt,obapp=PSC,o=Oblix,o=company,c=us
Deleting following entry
obSeqNo=3,cn=UserMgmt,obapp=PSC,o=Oblix,o=company,c=us
Deleted successfully
Deleting following entry
obSeqNo=2,cn=UserMgmt,obapp=PSC,o=Oblix,o=company,c=us
Deleted successfully
Adding GSN entry
obSeqNo=3,cn=UserMgmt,obapp=PSC,o=Oblix,o=company,c=us
Recovery of user sync records completed successfully
############################# Finished #############################.
To check the log file after GSN corruption detection or recovery
On the computer where you performed detection or recovery, locate recovergsncorruption.log in the following path:
PolicyManager_install_dir\access\oblix\tools\recovergsncorruption\
Review the messages to see what was detected, removed, added, or if there was any failure and why.
If the logged details, including references to sync records created by the tool, are not required, you can delete the log.
You perform this task after sync record corruption is detected. You must be a Master Access Administrator to perform this task.
To disable Access Server cache flush, you must set the 'doAccessServerFlush' parameter to false in the basedbparams.xml file of each Identity Server. This prevents the Access Manager SDK from sending requests to flush the Access Server cache. For more information, see the topic on "Configuring the Access Manager SDK for the Identity System" in the Oracle Access Manager Identity and Common Administration Guide.
After a successful recovery, you can undo this operation, as described in "Restoring Cache Flush Operations".
To disable cache flush between the Identity Server and Access Server
Locate the basedbparams.xml file in the following Identity Server path:
IdentityServer_install_dir/identity/oblix/data/common/basedbparams.xml
In the basedbparams.xml file, locate the doAccessServerFlush parameter and set it to false.
<NameValPair ParamName="doAccessServerFlush" Value="false" />
Save the file.
Restart the Identity Server.
Restart the Access Server.
Repeat these steps for all Identity Servers and restart servers one by one.
Proceed to "Blocking Updates from the Policy Manager and Applications using AMAPI".
After disabling cache flush operations between the Identity Server and Access Server, you need to block updates that occur automatically based on settings defined in the System Console. You do this by disabling the Update Cache option in the System Console.
Update Cache: This option must be turned off on the following pages:
Identity System Console: There are no Update Cache options on pages in the Identity System Console
Policy Manager: Nearly all pages related to a policy domain provide an Update Cache option. See the:
My Policy Domains page
Pages under the Resources tab
Pages under the Authorization Rules tab
Pages under the Default Rules tab
Pages under the Policies tab
Access System Console: Several pages under the Access System Configuration tab include an Update Cache option that must be disabled. See:
Authentication Management page and individual authentication scheme tabs: General, Plugins, Steps, and Authentication Flow
Common Information Configuration, Master Audit Rule tab
Host Identifiers, List all host identifiers page
Policy Manager API: In addition to turning off the Update Cache options, you must ensure that the Policy Manager API is off.
Note:
Policy Manager API and Access Management Service are used interchangeably in the System Console.You turn Policy Manager API functionality off in the following Access System Configuration pages:
Access Server Configuration
Access Server Clusters
AccessGate Configuration
After a successful recovery, you can undo this operation, as described in "Restoring Cache Flush Operations".
To block updates from the Policy Manager and applications
From the Access System Console, click the Access System Configuration tab, click Access Server Configuration, and perform the following steps:
Click the name of an Access Server.
Modify the Access Server configuration if needed to turn the Access Management Service Off.
Repeat these steps for all Access Servers.
From the Access System Configuration tab, click Access Server Clusters and perform the following steps:
Click the name of a cluster.
Confirm that the Policy Manager API Support Mode is off.
Repeat these steps for all Access Server clusters.
From the Access System Configuration tab, click AccessGate Configuration and perform the following steps:
Locate and click the name of an AccessGate.
Under the label Access SDK Client, confirm that the Access Management Service is Off.
Repeat these steps for all AccessGates that use the Access Server.
From the Access System Configuration tab, click Authentication Management and perform the following steps:
On the Authentication Management: List all Authentication Schemes page, confirm that the Update Cache option is not checked.
Click the name of an authentication scheme.
Click the General tab, click Modify and confirm that the Update Cache option is not checked.
Click the Plugins tab, click the name of a plug-in, and confirm that the Update Cache option is not checked.
Click the Steps tab and confirm that the Update Cache option is not checked.
On the Authentication Flow page, click a step name, and then confirm that the Update Cache option is not checked.
Repeat these steps for each authentication scheme you have defined.
From the Access System Configuration tab, click Common Information Configuration, and perform the following steps:
Click the Master Audit Rule tab.
Confirm that the Update Cache option is not checked.
From the Access System Configuration tab, click Host Identifiers, from the List all host identifiers page, confirm that the Update Cache option is not checked
You perform this task after blocking updates from the Policy Manager. You must be a Master Access Administrator to perform this task.
During recovery, the following processes are performed using the original sync records in the directory server:
Duplicate obSeqNo values in a single oblixGSN entry are removed from the directory server (oblixGSN objectclass will have a single unique ObSeqNo value)
Duplicate entries for the oblixGSN objectclass are removed from the directory server
Sync records for the deleted obSeqNo are updated. For example, deleted sync records might also be in a corrupted state after synchronization (the same as GSN entries), so recovergsncorruption attempts repair on these.
obSeqNo is updated with the maximum or largest ObSyncRequestNo
If recovery is not successful, you need to perform steps to revert to the earlier status of the directory server (the state before recovery was attempted). For more information, see "Correcting Errors that Occurred During the Recovery Process".
To recover from sync record corruption
Locate the recovergsncorruption command-line tool in the following path:
PolicyManager_install_dir\access\oblix\tools\recovergsncorruption\
Start detection and recovery by providing the following command-line arguments:
recovergsncorruption -i PolicyManager_install_dir -isCacheFlushDisabled yes
-recoverCorruption yes
Proceed as follows:
Error During Recovery Process: Proceed to "Correcting Errors that Occurred During the Recovery Process".
Recovery Completed Successfully: All corruptions have been resolved and cache flush will proceed without problem. In this case, you can restore cache flush operations as described in "Restoring Cache Flush Operations".
If the sync record recovery process occurred without error, you can skip this topic. You must be a Master Access Administrator to perform this task.
If errors occurred during sync record recovery, you can import the ldif file that was archived during the recovery process to restore sync records in the directory server to the state they were in before recovery began. The ldif contains entries for the oblixgsn objectclass (used in cache flushing) and obsyncrecord (describes what component has been flushed and what policy domain or policy it belongs to) under the PSC node. These were present before recovery was attempted.
The sync records ldif file that was created during the recovery process will be stored as follows:
PolicyManager_install_dir\access\oblix\data\common\
A naming convention of GSNsyncrecordsyear month day.hour minute seconds.ldif is used. For example:
GSNsyncrecords.20080729.040844.ldif
To recover from errors that occurred during the sync record recovery process
Confirm that the global sync number update is disabled as described in "Disabling Access Server Cache Flush and GSN Updates".
Confirm that updates from the Policy Manager and applications remain blocked as described in "Blocking Updates from the Policy Manager and Applications using AMAPI"
Locate the sync records .ldif file that was created during the recovery process. For example:
PolicyManager_install_dir\access\oblix\data\common\
GSNsyncrecords.20080729.040844.ldif
Run the commands for your directory server to import the ldif and restore the directory server to its state before recovery.
Proceed as follows:
Successful: You are finished.
Not Successful: You need to manually remove the corruption from the directory server. See your directory server documentation for details.
You must be a Master Access Administrator to perform this task.
After a successful recovery, you can enable Access Server cache flush by setting the 'doAccessServerFlush' parameter to true in the basedbparams.xml file of each Identity Server. You must also unblock updates from the Policy Manager.
To enable Access Server cache flush
Locate the basedbparams.xml file in the following Identity Server path:
IdentityServer_install_dir/identity/oblix/data/common/basedbparams.xml
In the basedbparams.xml file, locate the doAccessServerFlush parameter and set it to true.
Save the file.
Restart the Identity Server.
Restart the Access Server.
Repeat these steps for all Identity Servers and restart each server one by one.
Restore blocked updates from the Policy Manager and applications by reversing the actions you took to block these updates.
Update Cache: Turn on the Update Cache option on pages in Identity System Console, Policy Manager, and Access System Console.
Policy Manager API: Ensure that the Policy Manager API is on for the Access Server Configuration, Access Server Clusters, and AccessGate Configuration pages.
Note:
The terms "Policy Manager API" and "Access Management Service" are used interchangeably in the System Console.For details, see "Blocking Updates from the Policy Manager and Applications using AMAPI".
|
 Copyright © 2000, 2009, Oracle. All rights reserved. Legal Notices |
|