| Oracle® Access Manager Access Administration Guide 10g (10.1.4.0.1) Part Number B25990-01 |
|
|
View PDF |
| Oracle® Access Manager Access Administration Guide 10g (10.1.4.0.1) Part Number B25990-01 |
|
|
View PDF |
This appendix explains typical problems that you could encounter while running or installing Oracle Access Manager. It contains these sections:
This section describes common Oracle Access Manager error messages, problems and solutions. It contains the following topics:
When conducting a search, after the Search icon is selected an error page appears stating, "The following messages were produced by the product. Please contact your webmaster to fix the problem." The limitAMPolicyDomainResourceDisplay parameter is set to true in the Policy Manager globalparams.xml file.
Problem
The number of policy domains exceeds the current limit of 350. 400 policy domains were created in the Access System, each with 10 resources and 10 policies.
Solution
Do not exceed 350 policy domains with Active Directory.
The auditing feature for the Access Server is not working when auditing to a database. However, file-based auditing is working.
This problem can occur for various reasons when creating an RDBMS profile, as described in "Managing RDBMS Profiles" on page 7-35.
You may discover the problem after doing the following:
Create a new database instance and create an oblix_audit_events table in it, as specified in the chapter on auditing in the Oracle Access Manager Identity and Common Administration Guide.
Create an RDBMS profile in System Console, as specified in the chapter on auditing in the Oracle Access Manager Identity and Common Administration Guide.
In the Access System Console, click Access System Configuration, then click Access Server Configuration, then click the link for the Access Server that you want to modify.
Click Modify and ensure that you have turned on auditing to database and to a file.
In the Access System Console, click Access System Configuration, then click Common Information Configuration, then click Master Audit Rule.
Select the authentication success, authentication failure, authorization success and authorization failure events in the master audit rule.
Log in to Oracle Access Manager through a WebGate and check whether authentication and authorization success and failure events are being logged.
For example, you can check if a message, "The database audit writer was unable to perform the write," is logged in the Access Server's oblog.log file at the ERROR level.
You can also run the following command in either the SQL Server's Query Analyzer window or Oracle's iSQL*Plus window:
select * from oblix_audit_events
This command displays a list of existing audit records in oblix_audit_events table. If the list does not contain the new authentication and authorization events, it means that auditing to the database has failed.
The problem often occurs because of an incorrect value for the SQLDBType parameter in the following file:
Access_Server_install_dir/identity/apps/common/bin/globalparams.xml
Where Access_Server_install_dir is the location where the Access Server was installed. Set the value for the SQLDBType parameter as follows:
For an ODBC connection type, set the value to Oracle.
For an OCI connection type, set the value to Oracle_OCI.
For SQL Server database, set the value to SQLServer.
After logging in to one system (for example, the Access System) you may receive an error message similar to the following when you try to access the other system (for example, the Identity System):
The Identity Server logged you in but the Access System (Policy Manager or System Console) logged you out.
Problem
This may be due to one or more of the following problems:
Identity and Access Servers are running on different machines, and the clocks are set to a different time.
You have protected the Identity System in a policy domain, but not the Access System, or visa versa.
The loginslack parameter in the oblixbaseparams.xml file is not configured correctly.
Solution
Apply one or more of the following solutions:
Synchronize the Identity and Access Servers system clocks.
Ensure that policy domains have been created for both the Identity System and the Access System.
See "Protecting Resources with Policy Domains" for details.
Open the following file and edit the value for the loginslack parameter:
PolicyManager_install_dir/access/oblix/apps/common/bin/oblixbaseparams.xml
The loginslack parameter controls the time difference that is tolerated between the Policy Manager host computer and the Identity host computer. This parameter affects the WebPass, which controls single sign-on between the Policy Manager and the Identity System. It does not affect single sign-on provided by WebGate. This parameter is useful only if the WebGate is not protecting the Policy Manager or WebPass, and WebGate is not being used for single sign-on. In this type of scenario, the Policy Manager and WebPass use a cookie for login and single sign-on that is different from the ObSSOCookie. This cookie has time stamp.
The default value is 60 seconds.
Users can experience problems with single sign-on, including:
Unexpected session timeout.
Single sign-on failure (login prompts always are presented).
Authentication fails.
Users are authenticated initially, but their authorization fails when they access a resource on a second host.
After authenticating to a protected Web site, single sign-on does not work when accessing a second site that has the same authentication level.
Problem
The following may be causes for one or more problems:
Unexpected session timeout: the session timeout parameters are not configured correctly, or the system clocks on the hosts are not synchronized.
Single sign-on failure: The cookie definition may contain the wrong domain name, or the WebGates may not have the same primary HTTP cookie domain or shared secret.
The user's authentication fails: The user's identity or domain name does not match the authentication rules specified for the domain, or the authentication schemes to enable multi-domain single sign-on do not specify Challenge Redirect.
Users authorization fails when they access a resource on a second host: The authentication scheme configured for the second host be higher scheme than the one on the first host, or the shared secret may have been corrupted.
Solution
One or more of the following solutions may fix the problem:
Timeout problem:
Increase the value of the session timeout parameters Maximum User Session Time and Idle Session Time. See AccessGate Configuration Parameters for details.
Synchronize the system clocks on each host involved in single sign-on.
If the system clocks on the hosts are not synchronized, the cookie may be in the future or in the past and the session timeout rule may be triggered even though in reality there is no timeout issue
Single sign-on failure:
Check the definitions for the ObSSOCookie. The cookie definition may contain the wrong domain name.
Be sure that both WebGates have the same primary HTTP cookie domain.
Be sure the two WebGates are in the same installation, so that they are using the same shared secret.
The user's authentication fails.
Be sure this user's identity matches the authentication rules specified for the domain.
Also be sure the user supplied a fully qualified domain name. You can configure multiple ways for a user to specify the fully qualified domain name. See "Using Host Identifiers and Host Contexts" for details.
Finally, verify that, on the authentication schemes to enable multi-domain single sign-on, Challenge Redirect is set.
Users are authenticated initially, but their authorization fails when they access a resource on a second host.
The authentication rule configured for the second host could deny the requester access to the resource. A user can go from a higher scheme to a lower scheme, but not from a lower one to a higher one. For example, if a user is authenticated to access a resource that requires a Basic Over LDAP authentication scheme, that user can access other resources having the same or a less stringent scheme. However, if the same user tries to access a resource with a more stringent authentication challenge, such as Client Certificate, the user must re-authenticate.
Single sign-on does not work when accessing a second site that has the same authentication level.
The shared secret may have been corrupted. Regenerate the shared secret and restart the Web servers and Access Servers.
The login form repeatedly reappears after the user enters credentials.
Problem
The login form may continue to pop up due to the configuration of the parameters for login credentials, the configuration of the authentication plug-ins, and the configuration of the authentication scheme.
Solution
One of the following solutions can be applied to this problem.
Make sure the credentials in the creds challenge parameter for the form scheme match the input fields in the form.
Make sure the authentication plug-ins for the form scheme are correct.
If you are using IIS and the form action is not the webgate.dll, make sure the WebGate filter post processing is enabled by the Registry entry
HKEY_LOCAL_MACHINE\SOFTWARE\Oblix\Oblix COREid\version\WebGate\postdata="yes"
where version is the version number of the installed Oracle Access Manager product.
To make sure that the authentication scheme is set properly, you can attempt to access a resource protected with that authentication scheme, adding the credentials as query string parameters. This simulates a form whose method is GET without actually using the form.
For example, suppose the authentication scheme uses the following creds challenge parameter:
creds:login password
In this example, if the protected URL is http://server/protected/page.html, you could launch a browser instance and type the following:
http://server/protected/page.html?login=jsmith&password=MyPwd
If jsmith and MyPwd are valid credentials, after you press Enter the page is displayed instead of the login form if the authentication scheme is working correctly but something is wrong in the form's HTML code or in the registry (in the case of IIS servers).
To verify whether a user has a valid session, you can type the following in the browser's location:
javascript:altert(document.cookie)
The window that pops up should contain the current cookies associated with the browser, including the ObSSOCookie. This can also help determine if the cookie domain or invalid logout situations are affecting the login process.
After submitting a login form, you receive an error or the login form stops responding.
Problem
After you submit the login form, one or more of the following messages appears:
500 Internal Server Error
You receive an new login challenge (for example, a basic login dialog box)
If the form stops responding, the redirection action may be misconfigured.
Solution
If you receive an error message, ensure that the form's action URL is protected by a policy domain, and ensure that the action challenge parameter of the form scheme matches the form action URL.
If the form stops responding after successful authentication, be sure that the redirection action does not send the user back to the same login form.
You can find more solutions on Oracle MetaLink, https://metalink.oracle.com. If you do not find a solution for your problem, log a service request.
