| Oracle® Access Manager Access Administration Guide 10g (10.1.4.2.0) Part Number B32420-01 |
|
|
View PDF |
| Oracle® Access Manager Access Administration Guide 10g (10.1.4.2.0) Part Number B32420-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:
This section discusses the following topics:
Error Message to Check if the Directory Server is Running or Responding
Memory Usage Rises After Configuring a Directory Server Profile
During normal operations, you can receive an error indicating that the directory server may not be operational.
Problem
The Access Server or Policy Manager may issue one of the following error messages:
"Please verify that the Directory Server is running."
"Please verify that the Directory Server is responding."
These error messages are generated when the Oracle Access Manager component does not receive a response from the directory server within a user-configurable amount of time.
Solution
The following are possible solutions to the problem:
Check the value for the LDAPOperationTimeout parameter in globalparams.xml.
This parameter enables the Oracle Access Manager component to fail over to a secondary directory server when the primary one takes too long to respond. See the appendix on parameter files in the Oracle Access Manager Customization Guide for details.
Ensure that failover has been configured for this directory server.
See the information on configuring directory server profiles in the Oracle Access Manager Administration Guide. Also see the chapter on failover in the Oracle Access Manager Deployment Guide.
After configuring a directory server profile, the memory usage for the Access Server or Policy Manager becomes too high.
When you configure a directory server profile, you are prompted to provide a maximum session time. The default value for the session time is 0 (unlimited). This may cause a performance issue, because the size of the caches for LDAP connections to the Access Server and Policy Manager increase over time. Oracle Access Manager does not control these caches directly.
To prevent the cache size from causing a performance problem, set the value of the Maximum Session Time (Minutes) for the directory server profile to a finite value, for example, 10 hours, as follows:
From the Identity System Console click System Configuration, then click Directory Profiles.
Click the link for the profile that you want to modify.
In the Max. Session Time (Min.) field, set the value to 600.
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.
This section discusses the following issues:
WebGate Diagnostics URL Incorrectly Report that the Access Server Is Down
WebGate Is Unable to Connect to its Associated Access Server
The WebGate diagnostics URL reports the status of the Access Server or Servers to which the WebGate is connected. In some cases, the landing page for this URL can report that the Access Server or Servers are down when in the servers actually are running.
Problem
This problem occurs when the number of Access Servers that are associated with a WebGate is higher than the value of WebGate's Maximum Connections property. In this type of situation, the WebGate diagnostics page displays a status of Down for all Access Servers that exceed the Maximum Connections irrespective of their status.For example, suppose that you set the Maximum Connections value for WebGate A to 1 and you associate three Access Servers with it, AAA1, AAA2, and AAA3. The diagnostics page will indicate that AAA1 is up and AAA2 and AAA3 are down. If AAA1 is down, the page will indicate that AAA2 is up and AAA3 is down.
Solution
To fix this problem, ensure that there are more connections configured between the WebGate and the Access Servers than there are Access Servers. See "Viewing AccessGates" and "AccessGate Configuration Parameters" for details.
If you have installed a WebPass or a WebGate on IIS 6 and enabled logging, the WebPass or WebGate may be unable to connect to its associated Identity or Access Server.
Problem
This problem occurs when you send logs to an MPFileLogWriter. It does not occur when you send logs to a FileLogWriter.
The problem occurs with the MPFileLogWriter when there is no anonymous user with access to the directory that contains the log files. MPFileLogWriter uses a file named <logfile name>.lck to synchronize multiple processes that write to the corresponding log file. The MPFileLogWriter write-locks the.lck file before writing to the oblog.log file.
Solution
Configure an anonymous user with access to the directory that contains the log files. In some circumstances, the user context used to acquire the write-lock will be the IIS Anonymous web user. By default, this user is named IUSR_<computer name>, but you can configure any anonymous user for this purpose.
This section discusses the following issues:
On Microsoft Windows 2003, an Access Server or an Identity Server that has cache flushes to the Access Server may hang. This problem may be due to security changes in Microsoft Windows 2003 that cause the queue (Q) parameter that is sent to the Access Server to not take effect. The inability to set the number of queues leads to an insufficient number of available threads for the Access Server.
Requests are queued as they are sent to an Access Server. A thread processes each request. For example, if you have two request queues and 60 threads, the Access Server spawns 120 threads. The number of queues determines how many sets of threads are created for the Access Server process and determines the processing power of the Access Server.
Check to see if the Q parameter is being used in the startup command. You specify this parameter in the Services panel Start parameters field or via a registry key in the ImagePath parameter, as follows:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ObAAAServer-Access_Server_ID
If you use the queue (Q) parameter in your startup command, multiply the current number of threads in the Access Server configuration by the queue size, then update the number of threads using the result. For example, if you currently use 2 queues with 30 threads in the Access Server, change the number of threads to 60. You set this parameter from the Access Server configuration details page.
To configure the number of threads for the Access Server
Launch the Access System Console.
Click Access System Configuration, then select Access Server Configuration.
The existing Access Servers are listed on the page.
Select an Access Server to view its configuration.
The configuration details of the Access Server appear.
In the Number of Threads field, configure the maximum number of threads allowed for the Access Server.
The auditing feature for the Access Server is not working when auditing to a database. However, file-based auditing is working.
Problem
This problem can occur for various reasons when creating an RDBMS profile, as described in the chapter on configuring global settings in the in the Oracle Access Manager Administration Guide.
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 Administration Guide.
Create an RDBMS profile in System Console, as specified in the chapter on auditing in the Oracle Access Manager 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.
Solution
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.
This section discusses the following issues
The authentication scheme appears to be well-formed, and requests are being forwarded to the Access Server, but the user is not being authenticated.
Problem
After configuring an authentication scheme and testing it using the Access Tester, it appears that the scheme should work propertly. However, users are not being authenticated when they should be. Debug logs of the directory server do not show any sign of the Access Server performing a search in the directory server.
Solution
When adding the credential mapping plug-in to an authentication scheme, be sure that the credential_mapping plug-in is placed before the validate_password plug-in. The authentication scheme must process the plug-in that validates the attribute for the login ID before validating the password.
This section discusses the following issues
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.
This section discusses the following issues:
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:alert(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.
Note:
Because of the way Access System updates the Access Manager SDK caches that the WebGate uses, a corrected authentication scheme is not available until after that WebGate has made another request to the Access Server. Consequently, a form login problem may occur one more time after the correction.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.
Oracle Access Manager supports the capture of core dump information to the log files. You can also run and capture stack trace information. See the troubleshooting appendix in the Oracle Access Manager Administration Guide for details.
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.
