CA SiteMinder® Federation Standalone Guide › Troubleshooting

Troubleshooting

This section contains the following topics:

System Performance Troubleshooting

Resolving Signature Verification Failures

Two SSO Transactions Fail Using the Same Browser Session

Examine Secure Proxy Engine Logs to Troubleshoot the System

System Performance Troubleshooting

The following issue describes system performance troubleshooting.

Configure the Session Store Timeout for Heavy Load Conditions

Under heavy load conditions, long-running queries necessary for session store maintenance tasks, such as removing idled–out or expired sessions, can timeout. Adjust the timeout for session store maintenance tasks (60 seconds by default), by increasing the value of the MaintenanceQueryTimeout registry setting. Increase the value so that the maintenance thread can complete its tasks successfully.

The MaintenanceQueryTimeout registry setting can be found at the following registry location:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Netegrity\SiteMinder\CurrentVersion\
SessionServer

Proxy Engine Hangs and Stops Processing Requests

Symptom:

After processing requests for several days, CA SiteMinder® Federation Standalone's built-in proxy engine hangs.

Solution:

Modify tuning parameters in the proxy engine's server.conf for the connection between Apache web server (HTTP listener) and the proxy engine (Tomcat servlet engine).

The parameters you modify are used by the component mod_jk, which acts as the Tomcat connector to enable communication between the Apache web server and Tomcat using the Apache JServ protocol (AJP).

To modify the server.conf file

1. Navigate to the following directory:

   federation_install_dir/secure-proxy/proxy-engine/conf

2. Open the server.conf file in an editor.
3. Modify the following parameters

   worker.ajp13.reply_timeout

   Specifies the maximum time, in milliseconds, that can elapse between any two packets received from the proxy engine. After this timeout expires, the connection between the Apache server (HTTP listener) and the proxy engine is dropped. A value of 0 indicates that the proxy engine will wait indefinitely until a response is received.

   To ensure that the connection does not wait indefinitely for a response from the proxy engine, increase this value.

   Default: 0

   worker.ajp13.retries

   Indicates the maximum number of times that the mod_jk component sends a connection request to the proxy engine in case of a communication error. After the number of retries has been met and there is no response from the proxy engine, the connection is dropped.

   Increase this value for more retry attempts for a connection request.

   Default: 2

4. Save the server.conf file.

Resolving Signature Verification Failures

A malicious user can commit an XML signature wrapping attack by changing the content of a document without invalidating the signature. By default, software controls for the Policy Server and Web Agent Option Pack are set to defend against signature wrapping attacks. However, a third-party product can issue an XML document in a way that does not conform to XML specifications. As a result, the default signature checks can result in a signature verification failure.

Signature verification failures occur for the following reasons:

• A duplicate ID element is in the XML document and the signature references this duplicate ID. Duplicate ID attributes are not permitted.
• The XML signature does not reference the expected parent element, and a signature wrapping vulnerability is logged.

If a federation transaction fails, examine the smtracedefault.log file and the fwstrace.log file for a signature verification failure. These errors can indicate that the received XML document is not conforming to XML standards. As a workaround, you can disable the default Policy Server and Web Agent protection against signature wrapping attacks.

Important! If you disable the protection against signature vulnerabilities, determine another way to protect against these attacks.

To disable the XML signature wrapping checks:

1. Navigate to the xsw.properties file. The file exists in different locations for the Policy Server and the Web Agent.
   • For error messages in the Policy Server smtracedefault.log file, go to siteminder_home/config/properties
   • For error messages in the Web Agent fwstrace.log, go to

     web_agent_option_pack_ home/affwebservices/web-INF/classes.

     Note: If the web agent option pack is installed on the same system as the web agent, the file resides in the web_agent_home directory.

2. Change the following xsw.properties settings to true:
   • DisableXSWCheck=true (Policy Server setting only)
   • DisableUniqueIDCheck=true (Policy Server and Web Agent Option Pack setting)

     Note: The value of the DisableUniqueIDCheck setting must be the same for the Policy Server and the Web Agent Option Pack.

3. Save the file.

Two SSO Transactions Fail Using the Same Browser Session

Symptom:

A user attempts two single sign-on transactions in the same browser session. The transactions are from the same asserting party to different relying parties. The first transaction is successful but the second transaction results in an authorization failure at the asserting party. The failure occurs because the two partnerships are configured to use different asserting party user directories.

When CA SiteMinder® Federation Standalone initiates a single sign-on transaction at the asserting party, it places a session cookie in the browser. This session cookie contains information about the user ID and the asserting party user directory. Only one CA SiteMinder® Federation Standalone session cookie can exist in the browser at a time.

When a user attempts a second transaction in the same browser session as the first transaction, the session cookie for the first transaction remains in the browser. However, this session cookie does not have the correct information for the second partnership and the authorization operation fails.

Solution:

Use the same browser session for different single sign-on transactions only if the asserting party user directory for each partnership is the same.

If different asserting party user directories are configured for each partnership, close the first browser session and start a new browser session to attempt the second transaction.

Examine Secure Proxy Engine Logs to Troubleshoot the System

Partnership-based CA SiteMinder® Federation Standalone contains a secure proxy engine that forwards traffic to backend servers. The secure proxy engine includes the following components:

• Apache Web Server

  Acts as the HTTP listener, handling HTTP traffic for incoming requests, and can handle HTTPS traffic, once properly configured.

• Tomcat server

  Provides a servlet container for the operation of the Administrative UI. The Apache web server communicates to the Tomcat server through a Tomcat connector named mod_jk.

You can supply CA Support with log files related to these components to troubleshoot problems in your CA SiteMinder® Federation Standalone environment.

Two Apache logs that aid CA SiteMinder® Federation Standalone troubleshooting are:

mod_jk.log

mod_jk.log is enabled by default with the product. After the first contact with the federation server, information begins logging to this file.

To modify this log file:

1. Navigate to federation_install_dir\secure-proxy\httpd\conf
2. Open the httpd.conf file.
3. Set the following lines in the file to reflect these settings:

   JkLogFile "path_to_mod_jk_log"
   

   JkLogLevel debug
   

   JkRequestLogFormat "%w %V %T %m %h %p %U %s"
   

   Note: The path "logs/mod_jk.log" is the default location for the JkLogFile the entry. Use the default or set this path to your preferred location.

To disable the mod_jk.log, comment out or remove these lines from the file.

httpclient.log

For debug purposes only, you can enable the httpclient.log. The httpclient.log file is located in federation_install_dir\secure-proxy\proxy-engine\logs.

To modify this log file:

1. Navigate to federation_install_dir\secure-proxy\proxy-engine\conf.
2. Open the server.conf file
3. Change the following line:

   httpclientlog="yes"
   

To modify the location of the httpclient.log file and the log level, edit the httpclientlogging.properties file. Locate this file is in the directory federation_install_dir\secure-proxy\Tomcat\properties.