My Oracle Support Banner

Troubleshooting Single Sign-On and How to Log a OSSO Service Request (Doc ID 248870.1)

Last updated on SEPTEMBER 18, 2019

Applies to:

Oracle Application Server Single Sign-On - Version 9.0.4 to 10.1.4.3 [Release 10gR1 to 10gR3]
Information in this document applies to any platform.
***Checked for relevance on 11-Mar-2015***


Details

This article is a list of basic diagnostic steps that should be performed when trying to diagnose a problem with Oracle AS Single Sign-On (OSSO).

It also provides a list of the basic diagnostic information to be provided when logging a Single Sign-On (OSSO) related Service Request (SR) and provide links to further OSSO troubleshooting advice.

This is applicable to anyone reporting or researching any sort of SSO issue.
This applies to OracleAS 10g version 9.0.4, version 10.1.2 and version 10.1.4.

Actions

Information to provide when logging a SSO SR

It is recommended that article 339016.1 should be used to collect the relevant configuration information.


1. List the exact 5 digit version of all components, especially the core infrastructure version, the OID version, the SSO version and the RDBMS version, particularly if the default RDBMS has not been used. Include any patches or patchsets applied and the sequence in which they were applied.

The SSO version is reported by the report generated in item 8 below. See note (i) below for confirming versions of OID. Note (iii) for the RDBMS.

2. Connect to http://<SSO_HTTP_SERVERNAME>:<HTTP_PORT>/pls/orasso

3. Connect to http://<SSO_HTTP_SERVERNAME>:<HTTP_PORT>/oiddas

4. If there were no errors for the above tests, repeat the same simple connection test for any midtier applications that are configured or for a protected page on the midtier. Report the results for each midtier and include the URLs displayed and the HTML page source of the SSO login screen. Indicate any installed midtiers that do not have a problem.

5. Confirm the browser and browser versions that display the problem. If possible always try the same operation with more than one browser type. Even if the problem does occur with both Microsoft and Mozilla based browsers, the exact errors may differ slightly, thus providing important clues.

6. Set up the Mozilla based browser to prompt when cookies are set. Make a note of the cookies names and domains and when they appear.

DISCLAIMER: Oracle is not responsible for instructions/information from 3rd party sites that may be contained in this KM note

7. Create HTTP header trace from the browser and upload the results. This is probably the single most important information required for resolving SSO issues.
For Internet Explorer an example tool is available at: https://iehttpheaders.apponic.com/
- This program runs inside the IE Browser and will show all information as it is passed back and forth. It appears as an option under View, Explorer Bar.
For Mozilla based browsers, like Netscape or Firefox a suitable tool is available at: http://livehttpheaders.mozdev.org/
- LiveHTTPheaders runs as an extension to Mozilla based browsers. It appears as an option under Tools, Web Development.
Another alternative is fiddler2. This will work with all popular browsers though it is a bit more complex than the above two plug-ins. It is available via Microsoft. For documentation and download start at http://msdn.microsoft.com/en-us/library/bb250446(VS.85).aspx

NOTE: Oracle is not responsible in any way for supporting these tools or for any consequences of downloading or using them.


An alternative for HTTP requests (not so easy with HTTPS) is to use WireShark to capture the net packets. WireShark can be obtained from http://www.wireshark.org/, see article 416946.1.

8. Create an SSO configuration tables report article 244112.1. Using article 339016.1 will also include this report.

9. Describe the configuration. If a picture or diagram is available, that is preferred, but if not then something like the following example:

Browser <https> Firewall <https> Webcache <http> SSO Server/infra
.................................\\\\\\\\
..................................\\\\\\\\<http> Portal midtier


Provide host names, port numbers and IP addresses wherever possible.
Include any virtual host names configured as well as the physical host names.
e.g.

WebCache - <WEBCACHE_SERVERNAME>.<COMPANY>.com:<HTTP_SSL_PORT>/<HTTP_NONSSL_PORT> (111.111.111.111)
SSO server - <SSO_HTTP_SERVER>.<COMPARNY>.com:<HTTP_PORT> (22.22.22.22)
Portal Midtier - <PORTAL_SERVERNAME>.<COMPANY>.com:<HTTP_PORT> (99.99.99.99)
Load balancer (LB) if there is one, along with any rules configured.
Reverse proxy (RP) if configured, again along with the rules configured.


List the firewall port numbers opened to the internet.
Describe precisely the steps followed to obtain the current configuration.
Include tests performed between each step (Basic functionality testing such as described in 1, 2 and 3 above should have done between each step).
Add as much information as possible about the intended system configuration and the reasons why this configuration is desired.

10. If the configuration ever worked before the problem occurred, then describe everything that changed between the time when the system worked and when the first error was seen, however irrelevant it may seem. Include system reboots, component restarts, any reconfiguration steps, OS changes, network changes. One thing is certain, something has changed to cause the error.

11. If any custom deployment login, changepassword or signoff pages are used then test with the default pages to ensure the problem is not with the custom pages. If it is, then provide the page source and the $ORACLE_HOME/sso/conf/policy.properties file.

12. If a problem with a reverse proxy or WebCache returning bad HTTP headers is suspected, for example WWC-41439 is returned for /pls/orasso login, then the following test is very useful:

   Connect as user orasso to the metadata repository database
   SQL> CREATE OR REPLACE  PROCEDURE "ORASSO"."CGIENV" is
         begin
          owa_util.print_cgi_env;
         end;

   SQL> grant execute on orasso.cgienv to public;

Use this URL in a browser, e.g.

    "http://<SSO_HTTP_SERVERNAME>:<HTTP_PORT>/pls/orasso/orasso.cgienv"

Alternatively see article 413631.1 How to Check the Secure HTTP Headers Passed to a OC4J Application.

For more detail on this subject see article 269820.1 mod_osso's Final Redirect back to the Protected Application.

13. Other configuration files and logs to check and to provide.
A Portal Diagnostic Agent (PDA) report article 169490.1 or a Remote Diagnostic Agent (RDA) report article 314422.1. The PDA or RDA should include the OHS configuration files, but if these reports are not supplied then the following files are the most often of use:

$ORACLE_HOME/Apache/Apache/conf (Unix/Linux)
%ORACLE_HOME%\Apache\Apache\conf (Windows)
httpd.conf
ssl.conf
mod_osso.conf
oracle_apache.conf
$ORACLE_HOME/sso/conf (Unix/Linux)
%ORACLE_HOME%\sso\conf (Windows)
policy.properties
sso_apache.conf
$ORACLE_HOME/opmn/logs (Unix/Linux)
%ORACLE_HOME%\opmn\logs (Windows)
OC4J~OC4J_SECURITY~default_island~1

Take care that the tier where the configuration files are from is clearly identified.

For version 9.0.4 or above increase the SSO server debug level to DEBUG and upload the $ORACLE_HOME/sso/log/ssoServer.log.

See Oracle Application Server Single Sign-On Administrator's Guide 10g (9.0.4) Appendix A Troubleshooting - Increasing the Debug Level

or Oracle Application Server Single Sign-On Administrator's Guide 10g Release 2 (10.1.2) Appendix A Troubleshooting OracleAS Single Sign-On - A.6.2 Increasing the Debug Level

or Oracle Application Server Single Sign-On Administrator's Guide 10g Release 2 (10.1.4.0.1) Appendix A Troubleshooting OracleAS Single Sign-On - A.5.2 Increasing the Debug Level

It is recommended that article 339016.1 should be used to collect the relevant configuration information.

 

Notes on confirming versions

i) To confirm the OID version use the following command:

 > ldapsearch -h <OID_HOSTNAME> -p <LDAP_NONSSL_PORT> -s base -b "" "(objectclass=*)" "orcldirectoryversion"


To confirm the versions of the installed schemas:

  > ldapsearch -h <OID_HOSTNAME> -p <LDAP_NONSSL_PORT> -D "cn=orcladmin" -w <ORCLADMIN_PASSWORD>
               -L -s sub -b "cn=OracleSchemaVersion" "(objectclass=*)" "*"

To check the version of the OID binaries:

 > oidldapd -version

ii) The report from step 8 will show the SSO version.

iii) To check the RDBMS version simply do a connect from sqlplus to the active database.

Contacts

To view full details, sign in with your My Oracle Support account.

Don't have a My Oracle Support account? Click to get started!


In this Document
Details
Actions
 Information to provide when logging a SSO SR
 Notes on confirming versions
Contacts
References

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.