|
Oracle® Application Server Single Sign-On Administrator's Guide
10g Release 2 (10.1.2) Part No. B14078-01 |
|
 Previous |
 Next |
|
Oracle® Application Server Single Sign-On Administrator's Guide
10g Release 2 (10.1.2) Part No. B14078-01 |
|
|
Previous |
Next |
This appendix contains the following topics:
These OracleAS log files record data about single sign-on operations.
General log file for the single sign-on server:
ORACLE_HOME/sso/log/ssoServer.log
Usage Notes:
The single sign-on server writes all errors to this file. You can change the default location by editing ORACLE_HOME/sso/conf/policy.properties. You can also use this file to change the logging level.
Startup error log for single sign-on server:
ORACLE_HOME/opmn/logs/OC4J~OC4J_SECURITY~default_island~1
Usage Notes:
This OC4J-generated file reports any errors that occur when the single sign-on server is started. Check the file for error messages if the opmnctl command hangs or if it reports errors on the command line when the OC4J_SECURITY instance is started.
Web application log:
ORACLE_HOME/j2ee/OC4J_SECURITY/application-deployments/sso/OC4J_SECURITY_default_island_1/application.log
Usage Notes:
This file reports run-time errors for OC4J applications.
OC4J servlet access log:
ORACLE_HOME/j2ee/OC4J_SECURITY/log/OC4J_SECURITY_default_island_1/default-web-access.log
Usage Notes:
Another OC4J-generated file. The file contains the servlet access logs for single sign-on. Check the file to determine whether the authentication request was received by the authentication servlet.
Error log for Oracle HTTP Server:
ORACLE_HOME/Apache/Apache/logs/error_log
Usage Notes:
If the Oracle HTTP Server is configured to rotate its log files, it appends a timestamp to these files. Use this timestamp to find the latest file.
Access log for Oracle HTTP Server:
ORACLE_HOME/Apache/Apache/logs/access_log
Usage Notes:
If the Oracle HTTP Server is configured to rotate its log files, it appends a timestamp to these files. Use this timestamp to find the latest file.
This section explains how to address error messages and other problems. It devotes sections to the following:
Verify that the single sign server was started correctly. To do this, examine the startup log file for errors.
If the file reports errors for the database or for Oracle Internet Directory, make sure that both are up and running before starting the single sign-on server. If you see the message SSOLoginServlet.init: SSO server started, the server has been started correctly.
Next, check ssoServer.log, the log file for the single sign-on server.
If the log file contains the error message NumberFormatException or a specific configuration parameter not found, check policy.properties for blank spaces. Remove spaces that occur at the end of the line containing the questionable configuration; then restart the OC4J_SECURITY instance:
ORACLE_HOME/opmn/bin/opmnctl restartproc process-type=OC4J_SECURITY
If the file ORACLE_HOME/opmn/logs/OC4J~OC4J_SECURITY~default_island~1 reports the error message Orion Launcher SSO Server initialization failed, do the following:
Make sure that the database is available; then restart the single sign-on server:
ORACLE_HOME/opmn/bin/opmnctl restartproc process-type=HTTP_Server ORACLE_HOME/opmn/bin/opmnctl restartproc process-type=OC4J_SECURITY
If the database is available, the problem may be the directory connection. Check the opmn log. If you see the error message that follows, run ssooconf.sql to ensure that directory access is properly configured in the single sign-on database.
java.lang.NumberFormatException: null at java.lang.Integer.parseInt(Integer.java:442) at java.lang.Integer.parseInt(Integer.java:524) at oracle.security.sso.server.conf.DatabaseConfigReader. setSSOServerConfig(DatabaseConfigReader.java:322)
To learn how to run ssooconf.sql, see "Changing Single Sign-On Server Settings for Directory Access" in Chapter 3.
ssoServer.log for a detailed description of the message; then try restarting the database or the directory, depending upon what you find.
policy.properties file may be misconfigured, or Java classes may not be loaded. Another cause may be that the partner application is registered incorrectly.
ssoServer.log for the actual error message. If this file does not contain the message, check the Oracle HTTP Server error log. In the second case, try to log in to the administration pages:
http://single_sign-on_host:single_sign-on_port/pls/orasso
Be sure to log in as orcladmin, not as cn=orcladmin. If you are able to log in, the problem is not with the server, but with the partner application registration or with the application itself.
Check the Oracle HTTP Server error log.
If you find the message file not found, Apache is not delegating the authentication request to OC4J.
Check mod_oc4j.conf for single sign-on application mappings. The mount configuration Oc4jMount/sso OC4J_SECURITY should be present.
Check default-web-access.log to determine whether the authentication request was received by the servlet.
dads.conf file.
Update ORACLE_HOME/Apache/modplsql/conf/dads.conf.
Restart the Oracle HTTP Server:
ORACLE_HOME/opmn/bin/opmnctl restartproc process-type=HTTP_Server
If the schema password is correct to begin with, check the Oracle HTTP Server error log for error messages.
init.ora file.
processes and sessions parameters to match anticipated load. Use a database-specific configuration file such as init.ora to make the change. init.ora is found at ORACLE_HOME/dbs.
Case 1: The PUBLIC user entry is missing from Oracle Internet Directory. Either that or the user nickname attribute was changed in the directory, but the new attribute was not added to the PUBLIC entry.
Case 2: The single sign-on server is configured with the wrong information for the directory.
Case 3: There may be installation problems, namely, a missing Enabler entry or faulty SSL registration.
Case 4: The directory DIT has changed and the single sign-on server has not been updated with the changes.
Case 1: Add the PUBLIC user entry under the user search base in the directory. If, instead, the user nickname attribute was changed, add the attribute to the PUBLIC user entry.
Case 2: Run ssooconf.sql to configure the single sign-on server with the correct directory information. To learn how to run the script, see "Changing Single Sign-On Server Settings for Directory Access" in Chapter 3.
Case 3: Run ssooconf.sql to update the single sign-on server with the enabler entry or to modify single sign-on URLs for SSL.
Case 4: Run ssoreoid.sql to update the single sign-on server with directory DIT changes.
Try binding to the directory as the user, making sure that the user DN corresponds to the appropriate realm:
ORACLE_HOME/bin/ldapbind -h directory_server -p directory_ssl_port -D user_dn -w user_password -u 1
If the bind fails, the user's password is incorrect. Reset the password. If the bind succeeds, proceed to step 2.
Try binding to the directory as the single sign-on server:
ORACLE_HOME/bin/ldapbind -h directory_server -p directory_ssl_port -D orclApplicationCommonName=ORASSO_ SSOSERVER,cn=SSO,cn=Products,cn=OracleContext -w single_sign-on_server_password
If the bind fails, the server password that you are trying to bind with may be incorrect. To set the correct password, run ssooconf.sql as explained in "Changing Single Sign-On Server Settings for Directory Access" in Chapter 3. If the bind succeeds, proceed to step 3.
Check whether the single sign-on application is a member of the SecurityAdmins group. If it is not a member of this group, it cannot authenticate the user:
ORACLE_HOME/bin/ldapcompare -h directory_host -p directory_ssl_port -D orclApplicationCommonName=ORASSO_ SSOSERVER,cn=SSO,cn=Products,cn=OracleContext -w orasso_password -b "cn=user_dn,cn=users,realm_dn" -a userpassword -v user_password
If the application is not a member, add it to the SecurityAdmins group (cn=OracleUserSecurityAdmins,cn=Groups,cn=OracleContext) and have the user reauthenticate. If the application is a member, the problem may be directory based.
cn=iASAdmin,cn=Groups,cn=OracleContext,realm_dn
uniquemember attribute of the iASAdmins entry in the directory:
ldapsearch -h directory_host -p directory_port -D orclApplicationCommonName=ORASSO_ SSOSERVER,cn=SSO,cn=Products,cn=OracleContext -w orasso_password -b "cn=iasadmins,cn=groups,cn=oraclecontext,realm_dn" "uniquemember=cn=user,cn=users,realm_dn"
If the user in the command is not a unique member of iASAdmins, follow the instructions in "Granting Administrative Privileges" in Chapter 2.
cn=iASAdmins,cn=Groups,cn=OracleContext,dc=default_identity_management_realm
If you have changed the SSO administration group, make sure that the user is a member of this group.
This section explains how to debug certificate authentication; then it explains how to interpret error messages.
Set the debug level in policy.properties to DEBUG; then restart the single sign-on middle tier:
ORACLE_HOME/opmn/bin/opmnctl restartproc process-type=HTTP_Server ORACLE_HOME/opmn/bin/opmnctl startproc process-type=OC4J_SECURITY
To view browser certificate information while debugging, extract the file certinfo.jsp file from ORACLE_HOME/sso/lib/ipassample.jar.
Place the file into ORACLE_HOME/j2ee/applications/sso/web/jsp.
View the file at this URL:
https://host:port/sso/certinfo.jsp
SSLVerifyClient is missing from httpd.conf or has not been entered correctly.
ssoServer.log for details.
Case 1: The user's certificate is not in the browser.
Case 2: The SSL wallet on the Oracle HTTP Server may not contain the trusted certificate of the CA that issued the client certificate.
Case 1: Install a valid certificate.
Case 2: Use Oracle Wallet Manager to determine whether the SSL wallet contains the trusted certificate. To learn how to use the tool, see the chapter about managing wallets and certificates in Oracle Application Server Administrator's Guide.
x509CertAuth.properties or is incorrect.
CertificateMappingModule. If it is assigned, check that this value is correct.
ssoServer.log for details.
orclIsEnabled attribute in Oracle Internet Directory, but the user can still log in.
orclIsEnabled attribute is incorrect.
ldapbind from the command line as the user. If this act invokes an "account disabled error," reenter the attribute value.
orclIsEnabled attribute in Oracle Internet Directory, but the user receives an "authentication failed error" instead of an "account disabled" error.
When a user sees a WWC-41400 error, it usually means that the single sign-on server is configured incorrectly. The most common errors involve mod_osso-protected sites that have been reconfigured. Either the site2pstoretoken parameter is invalid or the site_id parameter is missing from the ORASSO.WWSSO_PAPP_CONFIGURATION_INFO$ table. Use the following steps to check these parameters:
Try to log in to a protected application. Make a note of any URLs that you use.
Display and save the HTTP page source of the single sign-on login page.
In the page source, search for the text site2pstoretoken. If the parameter is present, it should consist of three elements separated by the tilde character. The middle element in site2pstoretoken is the site ID. Here are two examples:
Release 9.0.2:
"v1.2~1321~C4C41209C8E4F0E3E8D.........."
Release 9.0.4 or 10.1.2
"v1.4~2F02C369~121CBBEE9920CDB.........."
If any one of these elements is missing, site2pstoretoken is invalid.
If site2pstoretoken is valid, determine whether the site ID is missing from single sign-on configuration tables. Log in to the single sign-on schema as orasso; then use SQL*Plus to search for site_id in the ORASSO.WWSSO_PAPP_CONFIGURATION_INFO$ table. See Appendix B to obtain the schema password.
WWC-41400 errors may be generated under the following conditions:
site2pstoretoken. Users see a WWC-41400 error after presenting their credentials.
site2pstoretoken and pass it back to the single sign-on server.
osso.conf file is referenced in the OssoConfigFile directive of the mod_osso.conf file. This file is found at ORACLE_HOME/Apache/Apache/conf. It may have been overwritten accidently. If you determine that the osso.conf file is incorrect, reregister the partner application. See "Registering mod_osso" in Chapter 4.
httpd.conf file—or the ssl.conf file if an HTTPS virtual host is defined—is missing the directives RewriteEngine On and RewriteOptions inherit. Invalid directives may be present as well.
OracleAS Single Sign-On provides four levels of debugging. They are listed here in ascending order of detail provided.
ERROR—log errors only
WARN—log both errors and warning messages
INFO—log informational messages—current date and time, for instance—as well as errors and warnings
DEBUG—log details about program execution as well as errors, warnings, and informational messages
In the course of debugging, you may have to increase the level of debugging to, say, DEBUG. You do this by modifying the file ORACLE_HOME/sso/conf/policy.properties.
After changing the debug level, restart the OC4J_SECURITY instance:
ORACLE_HOME/opmn/bin/opmnctl restartproc process-type=OC4J_SECURITY
Occasionally you may need to debug the mod_plsql code used to access external applications. This task requires that you enable debugging on the single sign-on database and then view detail logs. Note that this procedure does not apply to the debugging of partner applications. Debugging information for these applications is stored only in ORACLE_HOME/sso/log/ssoServer.log.
To turn on mod_plsql debugging, log in to the ORASSO schema and run the ssolsdbg.sql script. See Appendix B to obtain the schema password. Be sure to uncomment the commented lines in the script before running it. A copy of the script is located at ORACLE_HOME/sso/admin/plsql/sso.
Here is the script:
set scan off;
set feedback ON;
set verify ON;
set pages 50000;
set serveroutput ON;
CREATE OR replace PROCEDURE debug_print (str VARCHAR2) AS
BEGIN
INSERT INTO wwsso_log$ VALUES (wwsso_log_pk_seq.nextval,
substr(str, 1, 1000),
sysdate, dbms_session.unique_session_id);
commit;
END debug_print;
/
show errors;
To query the debug logs, issue this command:
SELECT * FROM WWSSO_LOG$ ORDER BY ID;
To turn off debugging, log in to the ORASSO schema and create the PL/SQL script that follows. Be sure to include this step when you finish debugging. If you skip it, superfluous records are created in the database table. See Appendix B to obtain the schema password.
set scan off;
set feedback ON;
set verify ON;
set pages 50000;
set serveroutput ON;
CREATE OR replace PROCEDURE debug_print (str VARCHAR2) AS
-- PRAGMA autonomous_transaction;
BEGIN
null;
END debug_print;
/
show errors;
The administration pages for single sign-on use the DBMS_LDAP package to perform directory operations. You can obtain details about these operations in the debug logs for the single sign-on database. To pinpoint the error though, you must enable client-side LDAP tracing. In trying, for example, to determine why an administrator cannot see administration links on the single sign-on home page, you can determine the exact point at which an error is being returned by the LDAP client-side APIs. You can then find the trace results in the RDBMS trace files.
Follow these steps to perform client-side tracing:
Enable tracing by loading the debugonldap.sql package into the ORASSO schema:
SQL> connect orasso/password
See Appendix B to obtain the schema password.
Run the script:
SQL> @debugonldap.sql
debugonldap.sql looks like this:
set scan off;
set feedback ON;
set verify ON;
set pages 50000;
set serveroutput ON;
CREATE OR replace PROCEDURE debug_print (str VARCHAR2) AS
BEGIN
dbms_ldap.set_trace_level(65535);
INSERT INTO wwsso_log$ VALUES
(wwsso_log_pk_seq.nextval, substr(str, 1, 1000), sysdate,
dbms_session.unique_session_id);
commit;
END debug_print;
/
show errors;
Perform a single sign-on operation that raised an error or that requires debugging—logging in to the home page as an administrator, for instance.
Examine the LDAP client logs in the RDBMS trace directory. You can determine the location of this directory by connecting as SYS to the identity management infrastructure database and then issuing this command:
SQL> show parameter user_dump_dest
The value returned is the directory where trace files are written. Once in the directory, examine the file timestamps to find the relevant file.
If the client-side trace files fail to reveal the problem, enable server-side tracing, but perform client-side tracing first. To enable server-side tracing, see the chapter about logging, auditing, and monitoring in Oracle Internet Directory Administrator's Guide.
To disable tracing, load and run this package:
set scan OFF; set feedback ON; set verify ON; set pages 50000; set serveroutput ON; CREATE OR replace PROCEDURE debug_print (str VARCHAR2) AS BEGIN null; END debug_print; / show errors;
The single sign-on server records authentication failures and successes in the Oracle Identity Management database. In time, the audit table, ORASSO.WWSSO_AUDIT_LOG_TABLE_T, runs out of space. When this happens, this error message appears in database alert logs:
ORA-1654: unable to extend index ORASSO.AUDIT_INDEX1 by 128 in tablespace IAS_META
In addition, further authentication requests fail.
Be sure to monitor ORASSO.WWSSO_AUDIT_LOG_TABLE_T regularly. When it becomes full, either back up the table and free up space or add space. Note that this is an internal, product-specific table. This means that you can use SQL*Plus to clean up the table, but you cannot use this tool or any other tool to build reporting or monitoring scripts based on the table.
For performance reasons, the single sign-on server caches connections to Oracle Internet Directory. If the directory server has a scheduled or unscheduled outage, the single sign-on server is left holding bad directory connections, and users may encounter directory setup errors when they try to access external applications. If the LDAP connection cache is invalid, the Oracle HTTP Server must be restarted:
ORACLE_HOME/opmn/bin/opmnctl restartproc process-type=HTTP_Server
Use the following steps to determine whether the LDAP connection cache must be refreshed:
Connect to the single sign-on schema. See Appendix B to obtain the schema password.
Issue the following command:
SELECT * FROM WWSSO_LOG$
Restart the HTTP server if you see the following error in the log:
'INVALID LDAP CONNECTION CACHE: RESTART ORACLE HTTP SERVER'
Delete the error message from WWSSO_LOG$.
If you change values in Oracle Internet Directory, you must update the single sign-on server with the changes. If, for example, you change a user, subscriber, or group search base in the directory and fail to "notify" the single sign-on server, users under the modified container are unable to log in. The ssoreoid.sql script updates the single sign-on server with directory changes. To learn how to run the script, see "Updating the Single Sign-On Server with Directory Changes" in Chapter 3.
After running the script, make sure that you restart the single sign-on server:
ORACLE_HOME/opmn/bin/opmnctl restartproc process-type=HTTP_Server ORACLE_HOME/opmn/bin/opmnctl restartproc process-type=OC4J_SECURITY
Deploying geographically distributed single sign-on instances requires, among other things, that you replicate the identity management infrastructure database. Each time you replicate the database, you should validate the replication process on each replicated node and correct errors that you find. Use the Replication Environment Management Tool (remtool) to complete both tasks.
remtool is run on the master definition site. You can find the tool at ORACLE_HOME/ldap/bin. It can be executed in two modes as the sections that follow explain.
To verify that the directory replication group has been successfully configured, issue the following command:
remtool -asrverify
The command option -asverify instructs the tool to report on the verification as it progresses, but not to rectify problems.
To verify that a directory replication group has been successfully configured and to rectify problems, execute the following command:
remtool -asrrectify -v -connect repadmin/repadmin_password@net_service_name
The command option -asrectify instructs the tool to report on the verification as it progresses and to rectify problems. Table A-1 defines the two other command parameters.
Table A-1 Parameters for the Replication Environment Management Tool
For an in-depth look at the Replication Environment Management Tool, see the syntax chapter in Oracle Internet Directory Administrator's Guide.
The first page of a mod_osso-protected application must be a URL that uses the GET authentication method. If the POST method is used, the data that the user provides when logging in is lost during redirection to the single sign-on server. When deciding whether to enable the global user inactivity timeout, note that users are redirected after timing out and logging in again.
