| 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 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 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 Identity and Common 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 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.
Solution
The problem often occurs because of an incorrect value for the SQLDBType parameter in the following file:
AccessServer_install_dir/identity/apps/common/bin/globalparams.xml
Where AccessServer_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
Authentication Scheme Is Well Formed but User is Not Authenticated
Oracle Access Manager Fails While Authenticating (User Data in Netscape/Sun Directory Server)
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 properly. 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.
Problem
Oracle Access Manager fails while authentication a user when user data is stored in Netscape/Sun Directory Server and the login attribute is indexed using index ldif import.
Cause
This is an issue with the Netscape/Sun Directory Server. To index any attribute, the Sun ONE Sever Console should be used.
Solution
Follow the steps here.
To index an attribute using the Sun ONE Server Console
Log in to Sun ONE Server Console, and open related directory server instance.
Go to the Configuration tab, expand the Data node, and select the searchbase node (the suffix under which attributes are to be indexed). For example:
dc=us,dc=oracle,dc=com
In the right-hand panel, view the list of System Indexes and Additional Indexes.
Click the Add Attribute button to add attributes to be indexed and configure these for equality, presence, and substring matches.
Click Save which displays a warning.
Select Reindex Suffix and select attributes that you have recently added.
Click OK.
Problem
You might experience a problem that prevents adding large authorization expressions (for example, if you are using Oracle Internet Directory, the limit is 4000 characters). After adding and saving a large expression, you might see the following message:
No Authorization Defined
Cause
The source of the problem is a directory server limitation. However, some directory vendors support increasing the maximum attribute length.
Solution
Before you add a large authorization expression, the Policy Manager globalparams.xml file requires the addition of the policyDSMaxAttrValueLength parameter. The value that you add should be the maximum limit imposed on an attribute length by the directory server. For Oracle Internet Directory, this value should not exceed 4000 characters. For other directory servers, consult the vendor-specific documentation for further details.
If you are adding the policy using an API in the Access Manager SDK, then you need to add the policyDSMaxAttrValueLength parameter to the associated Access Server globalparams.xml file.
Note:
If the directory limit cannot be changed or cannot accommodate the size of the expression, the
policyDSMaxAttrValueLength parameter will instruct Oracle Access Manager to compensate for the limit and allow creation of larger expressions.To compensate for the limit and allow creation of larger expressions
Locate the globalparams.xml file in the following path:
For changes from the API of Access Manager SDK:
AccessServer_install_dir/access/oblix/apps/
common/bin/globalparams.xml
For changes from Policy Manager:
PolicyManager_install_dir/access/oblix/apps/
common/bin/globalparams.xml
Add the following lines anywhere in the globalparams.xml file:
<SimpleList>
<NameValPair
ParamName="policyDSMaxAttrValueLength"
Value="4000">
</NameValPair>
</SimpleList>
Restart the Access Server, or the Policy Manager Web server.
Add authorization expressions to Oracle Access Manager.
As described in Chapter 8, an Oracle Access Manager deployment can include multiple instances of the Identity Server, Access Server, and Policy Manager. To ensure behavioral consistency, all changes to a user profile or policy information (or configuration changes for Access Servers) are written to the directory server and must be propagated across all components.
Problem
On Access Server 10g (10.1.4.2.0) or later with Active Directory as the backend Directory Server, cache flush operations are not taking effect on the Access System. Additionally, schema violation error logs are observed in the Access Sever log file during cache flush operations.
Cause
A schema limitation in Active Directory.
Solution
With Active Directory as a backend directory server, you must set the value of the UserMgmtNodeEnabled parameter to false in the Access Server globalparams.xml file.
See Also:
The chapter on parameters in the Oracle Access Manager Customization GuideTo ensure proper cache synchronization with Active Directory
Locate the globalparams.xml file for Access Server:
AccessServer_install_dir\access\oblix\apps\common\bin\globalparams.xml
Confirm (or change) the value of the UserMgmtNodeEnabled parameter is set to false.
Restart the Access Server.
Repeat these steps for all Access Servers in the deployment.
Caution:
With original 10g (10.1.4.2.0) release, this was enabled by default. With bundle patch 10g (10.1.4.2.0)-07, the default is disabled (false) as it was for 10g (10.1.4.01).
With Oracle Access Manager 10g (10.1.4.3) (or 10g (10.1.4.2.0) bundle patch 07), UserMgmtNodeEnabled operates as expected: A value of true enables the function and a value of false disables it.
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 Identity and Common 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.
All command line utilities and tools must be run as the user who installed the product, as described in the Oracle Access Manager Installation Guide. Oracle recommends that you do not attempt to change ownership or permissions on files after installation.
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.
In either of the following situations, a 302 response appears in the Web browser when WebGate is installed with the Apache/Oracle HTTP Server 1.3.x Web server and you are accessing a resource that is protected with a form-based authentication scheme:
Either a challenge redirect is used
Or a reverse-proxy server is used to hide the Web server protected by WebGate
Problem
The 302 response contains the Location:url that is used, per the HTTP protocol, for the next request. The browser displays the following message:
Found
The document has moved here
Cause
The extra data is being populated by Apache/Oracle HTTP Server 1.3.x because of a protocol mismatch between the Proxy Server (or client) and Apache/Oracle HTTP Server. Oracle HTTP Server is based on Apache 1.x.x and the keepalive and HTTP/1.1 on Apache 1.3.27 are not properly implemented. In this case, the data is being transferred to the Proxy Server/client (browser) in the form of chunks. All the chunks are being collected in a temporary cache and the cache link is shown to the user.
Workarounds
There are several workarounds. Item #2 is the best possible solution and is Oracle's recommendation. There is a performance penalty with using HTTP 1.0 as opposed to HTTP 1.1. Workarounds 3, 4, and 5 should be used only if workarounds #1 and 2 are not feasible or do not work. Choose the workaround that is best for your environment:
Upgrade the APACHE/Oracle HTTP Server 1.3.X to a higher version.
Add the following line to the httpd.conf file of the WebGate Web server:
ErrorDocument 302 "
Add BrowserMatch directives in the "mod_setenvif" module of the httpd.conf file of the WebGate Web server to disable the keepalive for particular browsers.
Use two environment variables in the reverse-proxy httpd.conf file for protocol adjustments that can force the request to use HTTP/1.0 with no keepalive. For example:
1)force-proxy-request-1.0 2)proxy-nokeepalive
Configure your client browser setting to use the HTTP /1.0 protocol.
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.
Problem
This problem can occur in a new installation with default settings when you have multiple Access Servers configured with a single directory server. If one Access Server hangs during a cache flush request from the Policy Manager, the Policy Manager can hang when the Update Cache option is enabled and any parameter is modified and saved using the Policy Manager console. For instance, if you change a host identifier or Policy Domain, or URL prefix with the Update Cache option enabled.
Soution
Add the CacheFlushTimeOut parameter in the Policy Manager globalparams.xml file. For details, see "Configuring Synchronous Cache Flush Requests Between Multiple Access Servers with a Wait Period" in the Oracle Access Manager Deployment Guide.
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 computers, 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. The loginslack 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 configured for the same Access Server.
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 Challenge Redirect is set on the authentication schemes to enable multi-domain single sign-on.
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. Even if a user tries to access a resource protected by the same scheme (but with a higher level authentication challenge), 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:
Invalid or Missing Preferred HTTP Host Identifier in WebGate Profile
WebGate Diagnostics URL Incorrectly Report that the Access Server Is Down
Mismatch Between Content and Content Length in a Web Server 401 Response
New parameters are provided that you can use to leave the Preferred HTTP Host field empty, and to validate the entry in the field to ensure there are no errors:
AllowEmptyPreferredHost: When the value is true, the Preferred HTTP Host field can be empty in a WebGate configuration profile in the Access System Console.
When the value is false (or absent by default) the Preferred HTTP Host field cannot be empty. If it is empty, an error occurs when you save the profile.
PreferredHostValidityCheckEnabled: When the value is true (or not present by default) the value in the Preferred HTTP Host field is validated to catch any typographical errors.
See Also:
Knowledge base article 416329.1 on Oracle Metalink athttps://metalink.oracle.com. This note provides guidelines for deciding if you want to use the Preferred HTTP Host feature, and how to bypass it if you decide that enabling virtual hosting is more important in your environment than using the preferred host.To allow an empty Preferred HTTP Host field or check the validity of the value
Locate the wrsc_admin.js file and remove the validation from this script
Locate the Policy Manager globalparams.xml file in:
PolicyManager_install_dir/access/oblix/apps/common/bin/
Allow an Empty Preferred HTTP Host Field: Set AllowEmptyPreferredHost to true and save the file:
<SimpleList>
<NameValPair
ParamName="AllowEmptyPreferredHost" Value="true">
</NameValPair>
</SimpleList>
Enable a Validity Check of the Preferred HTTP Host: Set PreferredHostValidityCheckEnabled to true and save the file:
<SimpleList>
<NameValPair
ParamName="PreferredHostValidityCheckEnabled" Value="true">
</NameValPair>
</SimpleList>
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 AccessGate Profiles" 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.
It is possible that a Web server will send informative data with a 401 Web server response. A mismatch between the content and content length result in either no data displayed in the browser or an error message in the browser. After accessing the product URL with valid credentials on Mozilla, the following error is displayed:
HTTP Error 401 401.1 Unauthorized: Logon Failed This error indicates that the credentials passed to the server do not match the credentials required to log on to the server. Please contact the Web server's administrator to verify that you have permission to access the requested resource
However, when the browser is refreshed, the product home page is displayed.
With Miscosoft Internet Explorer, if the product URL is accessed with valid credentials a blank page is displayed, but after refreshing the page Product home page is displayed.
To configure WebGate to work with particular browsers, proxies, and so on, you can set specific user-defined parameters. A new WebGate user-defined parameter can be used to set the Content-Length to 0 for all 401 responses:
Parameter: ContentLengthFor401Response
Value: 0 (any other value will be ignored)
Note: WebGate is affected and must be patched.
To add the ContentLengthFor401Response parameter to WebGate configuration
Launch the Access System Console and click Access System Configuration.
Click AccessGate Configuration.
Enter your search criteria for the WebGate, and then click Go.
In the Search Results table, click a WebGate name.
At the bottom of the Details for AccessGate page, click Modify.
On the Modify AccessGate page, locate the User Defined Parameters section of the page, enter the following parameter, and value, and then click the Add button:
Parameter: ContentLengthFor401Response
Value: 0
Click the Add button if you want to add more user-defined parameters.
Save to save this new information.
Repeat for each WebGate in your deployment.
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 Identity and Common Administration Guide for details.
You can find more solutions on My Oracle Support (formerly MetaLink), https://metalink.oracle.com. If you do not find a solution for your problem, log a service request.
|
 Copyright © 2000, 2009, Oracle. All rights reserved. Legal Notices |
|