This section contains the following topics:
Policy Server Exits with LDAP Admin Limit Exceeded Error
Command Line Troubleshooting of the Policy Server
Policy Server Hangs after Web Agent Communication Failure
Check the Installed JDK Version
Override the Local Time Setting for the Policy Server Log
Review System Application Logs
LDAP Referrals Handled by the LDAP SDK Layer
Idle Timeouts and Stateful Inspection Devices
Error -- Optional Feature Not Implemented
Errors or Performance Issues When Logging Administrator Activity
Event Handlers List Settings Warning when Opening Policy Server Management Console
SiteMinder Policy Server Startup Event Log
Policy Server is Unable to Reconnect with Database
Symptom:
The Policy Server gracefully exits when LDAP search to Policy Store/Key Store fails with the following error:
LDAP_ADMINLIMIT_EXCEEDED (error code 11)
Solution:
Enable the following optional registry key:
EnableRetryOnAdminLimitExceededFailure
Allows the Policy Server to retry the search once before giving up.
Values: 0 (disabled) or 1 (enabled).
Default: 0
Windows
Follow these steps:
HKEY_LOCAL_MACHINE\SOFTWARE\Netegrity\SiteMinder\CurrentVersion\ObjectStore
EnableRetryOnAdminLimitExceededFailure
UNIX
Follow these steps:
install_directory/siteminder/registry
HKEY_LOCAL_MACHINE\SOFTWARE\Netegrity\SiteMinder\CurrentVersion\ObjectStore
EnableRetryOnAdminLimitExceededFailure
You can run the Policy Server process interactively in a separate window with debugging options turned on to troubleshoot problems. The following server executable may be run from the command line:
install_dir/siteminder/bin/smpolicysrv
Note: On Windows systems, do not run the smpolicysrv commands from a remote desktop or Terminal Services window. The smpolicysrv command depends on inter-process communications that do not work if you run the smpolicysrv process from a remote desktop or Terminal Services window.
Use the following options with the smpolicysrv command:
This option is used to modify the TCP port that the server binds to for Agent connections. If this switch is not used, the server defaults to the TCP port specified through the Policy Server Management Console.
This option is used to modify the UDP port that the server binds to for RADIUS connections. If this switch is not used, the server defaults to the UDP port specified through the Policy Server Management Console. This switch is applicable to the authentication and accounting servers only.
This switch stops the server in the most graceful manner possible. All database and network connections are closed properly using this method.
This switch stops the server immediately, without first closing database and network connections.
This switch produces current server runtime statistics such as thread pool limit, thread pool message, and the number of connections.
This switch resets the current server runtime statistics without restarting the Policy Server. This switch resets the following counters:
This switch does not reset the following counters:
Publishes information about the Policy Server.
Sets the TCP port for the administration service.
Sets the UDP port for Radius accounting.
Sets the UDP port for the administration service.
Sets the UDP port for Radius authentication.
Enables the servicing of Agent API requests.
Disables the servicing of Agent API requests.
Enables the servicing of administration requests.
Disables the servicing of administration requests.
Enables the servicing of RADIUS requests.
Disables the servicing of RADIUS requests.
Combines the following options into a single option:
The command:
If the Policy Server is already logging trace data, running the –starttrace command causes the Policy server to:
For example, if the trace file name in Policy Server Management Console’s Profiler tab is C:\temp\smtrace.log, the Policy Server generates a new file and saves the old one as c:\temp\smtrace.20051007_121807.log. The time stamp indicates that the Policy Server created the file on October 7, 2005 at 12:18 pm. If you have not enabled the tracing of a file feature using the Policy Server Management Console’s Profiler tab, running this command does not do anything.
The command:
You can use two smpolicysrv command line options, -dumprequests and -flushrequests, to troubleshoot and recover more quickly from an overfull Policy Server message queue. Only use these options in the following case:
!Important Do not use -dumprequests and -flushrequests in normal operating conditions.
Outputs a summary of each request in the Policy Server message queue to the audit log.
Flushes the entire Policy Server message queue, so that no requests remain.
You can start or stop the debugging function of certain components at any time without restarting the Policy Server.
Note: We recommend using this feature only when directed to do so by CA Technologies technical support personnel.
Follow these steps:
SmCommand -i SiteMinder
A list of options appears.
Toggles the debugging state of the SiteMinder EPM component.
Toggles the debugging state of the SiteMinder XPS component.
Toggles the debugging state of the SiteMinder XPSEvaluate component.
You can start or stop the tracing functions of certain components at any time without restarting the Policy Server.
Follow these steps:
SmCommand -i SiteMinder
item_number - CA.XPS::TraceOn
Toggles tracing for the EPM Objects components on or off.
Toggles tracing for the XPS components on or off.
Toggles tracing for the XPS Expression Evaluator components on or off.
A confirmation message appears. The list of options is redisplayed with your changes.
Tracing has been changed dynamically.
The Policy Server can sometimes fail to process events after deleting the following objects:
Cache failure timeout functionality addresses this issue.
When the secondary cache buildup is not successful, the policy server aborts after a timeout period. You specify the timeout period using the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Netegrity\SiteMinder\CurrentVersion\ObjectStore\CacheFailureTimeout
The value of this key is in seconds. The default is 0, which implies no timeout.
After the policy server shuts down, the smexec brings up the next process event request immediately.
Symptom:
If a Web Agent goes offline during a Policy Server request, for example, during a network outage, and does not notify the Policy Server of the communication failure, the Policy Server continues to wait for the Web Agent data. The Policy Server continues to wait, even after the Web Agent regains network functionality and closes the connection to the Policy Server.
If many requests from one or more Web Agents are lost in this manner, the Policy Server can become unresponsive because the worker threads handling the requests are not released.
Solution:
Creating and enabling the SiteMinder Enable TCP Keep Alive (SM_ENABLE_TCP_KEEPALIVE) environment variable configures the Policy Server to send KeepAlive packets to idle Web Agent connections. The interval at which the Policy Server sends the packets is based on OS–specific TCP/IP parameters.
Consider the following when configuring the parameters:
Note: For more information about configuring TCP/IP parameters, see your OS–specific documentation.
To configure the Policy Server to send KeepAlive packets to idle Web Agent connections
SM_ENABLE_TCP_KEEPALIVE
SM_ENABLE_TCP_KEEPALIVE=1
Note: The value must be 0 (disabled) or 1 (enabled). If a value other than 0 or 1 is configured, the environment variable is disabled. If the environment variable is disabled, the Policy Server does not send KeepAlive packets to idle Web Agent connections.
If a Policy Server fails to start, check that the correct version of the JDK is installed.
The Policy Server log file, install_dir/siteminder/log/smps.log, displays time in local timezone as identified by the operating system of the machine on which the Policy Server is installed.
To display the time in this log file in GMT time:
HKEY_LOCAL_MACHINE\SOFTWARE\Netegrity\SiteMinder\ CurrentVersion\LogConfig\LogLocalTime
If the Policy Server fails to start, review the event log (on Windows) or the syslog (on UNIX) for information about the Policy Server.
Enhancements have been made to SiteMinder’s LDAP referral handling to improve performance and redundancy. Previous versions of SiteMinder supported automatic LDAP referral handling through the LDAP SDK layer. When an LDAP referral occurred, the LDAP SDK layer handled the execution of the request on the referred server without any interaction with the Policy Server.
SiteMinder now includes support for non-automatic (enhanced) LDAP referral handling. With non-automatic referral handling, an LDAP referral is returned to the Policy Server rather than the LDAP SDK layer. The referral contains all of the information necessary to process the referral. The Policy Server can detect whether the LDAP directory specified in the referral is operational, and can terminate a request if the appropriate LDAP directory is not functioning. This feature addresses performance issues that arise when an LDAP referral to an offline system causes a constant increase in request latency. Such an increase can cause SiteMinder to become saturated with requests.
If LDAP referrals are causing errors, you can disable all LDAP referrals. Note that disabling LDAP referrals will cause any referrals in your directory to return errors.
To disable LDAP referral handling for Policy Servers on Windows
HKEY_LOCAL_MACHINE\SOFTWARE\Netegrity\SiteMinder\ CurrentVersion\Ds\LDAPProvider
Note: The value is shown in hexadecimal notation.
"EnableReferrals"=dword:00000001
Determines if any LDAP referrals are handled by the Policy Server. If set to 0, no LDAP referrals will be accepted by the Policy Server. If set to 1, the Policy Server accepts LDAP referrals.
LDAP referrals are enabled by default. This setting may only be modified by editing the Registry.
To disable LDAP referral handling for a Policy Server on Solaris
install_dir/siteminder/registry
HKEY_LOCAL_MACHINE\SOFTWARE\Netegrity\SiteMinder\ CurrentVersion\Ds\LDAPProvider
EnableReferrals
Note: The value must be converted to hexadecimal notation.
Determines if any LDAP referrals are handled by the Policy Server. If set to 0, no LDAP referrals will be accepted by the Policy Server. If set to 1, the Policy Server accepts LDAP referrals.
To configure LDAP referrals on bind operations for Policy Servers on Windows
HKEY_LOCAL_MACHINE\SOFTWARE\Netegrity\SiteMinder\ CurrentVersion\Ds\LDAPProvider
Note: The value is shown in hexadecimal notation.
"ChaseReferralsOnBind"=dword:00000001
Determines if LDAP referrals on a bind operation should be chased. Most LDAP directory servers handle LDAP referrals on binds. If your directory server handles referrals on binds, ChaseReferralsOnBind has no effect. However, if your directory does not, this setting allows the Policy Server to handle bind referrals.
If your server does handle referrals on bind operations you can change this setting to 0, disabling the Policy Server’s ability to handle bind referrals.
Referral chasing on binds is enabled by default. This setting may only be modified by editing the Registry.
To configure LDAP referrals on bind operations for a Policy Server on Solaris
install_dir/siteminder/registry
HKEY_LOCAL_MACHINE\SOFTWARE\Netegrity\SiteMinder\ CurrentVersion\Ds\LDAPProvider
ChaseReferralsOnBind
Note: The value must be converted to hexadecimal notation.
Determines if LDAP referrals on a bind operation should be chased. Most LDAP directory servers handle LDAP referrals on binds. If your directory server handles referrals on binds, ChaseReferralsOnBind has no effect. However, if your directory does not, this setting allows the Policy Server to handle bind referrals.
If your server does handle referrals on bind operations you can change this setting to 0, disabling the Policy Server’s ability to handle bind referrals.
Stateful inspection devices, such as firewalls, generally have an idle timeout setting. SiteMinder connections from Policy Servers to Agents also have idle timeout settings.
The Policy Server polls the services at a regular interval. The polling interval has a 5-minute cap. This means the idle connections will time out within 5 minutes of the configured value. For example, if the value 55 minutes is specified as the timeout, then the connections will time out between 55 and 60 minutes.
By default, connections created between a Policy Server and a Web Agent expire after 10 minutes of inactivity. If a firewall or other stateful network device exists between a Policy Server and a Web Agent and connections are idle for longer that the device’s idle timeout, then the device ends those connections without notifying either the Policy Server or the Web Agent.
When the Web Agent attempts to use a connection that has been terminated by a network device, it receives a network error, resets the connection, and reports a 500 error (20-0003) to the browser. The Agent also closes all other connections in the connection pool that are the same age or older than the one that received the error. On the Policy Server side, however, the sockets for those connections remain established. Depending on the load patterns for the site, connection growth can occur to a point that it interferes with the proper operation of the Policy Server.
To prevent a firewall or other stateful network device from terminating Policy Server – Web Agent connections, you must configure an idle timeout for Policy Server. When the Policy Server closes a TCP/IP connection, it will wait for a specified period of inactivity and then send RESET, closing the server and client ends of the connection cleanly. The period of inactivity is specified in the Idle Timeout (minutes) field on the Settings tab of the Policy Server Management Console.
Note: The Idle Timeout (minutes) field can also be used to limit the amount of time an administrator may be connected.
At installation, the Idle Timeout value is set to 10 minutes. To work with a stateful network device, set the value to a shorter time period than the TCP/IP idle timeout of the device that is located between the web agent and the policy server. It is recommended that the TCP Idle Session Timeout be set to 60% of the idle timeout of any stateful device(s) to ensure that the Policy Server’s timeout occurs first.
When the Policy Server attempts to use an ODBC data source, but cannot connect to the database, the following error message may appear:
Optional feature not implemented.. Error code -1
Often this message indicates a component mismatch, a misconfiguration or invalid credentials.
Note: CA's configuration of the Intersolv or Merant drivers differs from the default configuration.
If you receive the above message, and you are using an ODBC data source as your policy store, or for logging, see the sections that describe the configuration of ODBC data sources in the Policy Server Installation Guide.
On the Audit tab of the Policy Server Management Console, if you have set Administrator Changes to Policy Store Objects to Log All Events, and you are logging to an ODBC data source, you may encounter one of the following:
Exception occurred while executing audit log insert.
If either of these conditions occur, log to a text file instead.
When the Policy Server issues key rollover commands to Web agents, they can process the commands successfully some of the time, but other times, the commands fail. To facilitate troubleshooting in this situation, the Policy Server logs three types of messages to SMPS.log.
This message is logged when an administrator manually initiates a key rollover.
This message is logged when the Policy Server initiates a key rollover automatically.
This message is logged when a key rollover request has been initiated, either automatically or manually.
You can enable and disable cache flushing or updates through the Administrative UI or the Command Line Interface. To facilitate troubleshooting, the Policy Server logs two types of messages to SMPS.log.
This message is logged when cache flushing is enabled, either through the Administrative UI or the Command Line Interface.
This message is logged when cache flushing is disabled, either through the Administrative UI or the Command Line Interface.
Symptom:
When I log into the Policy Server Management Console for the first time after upgrading to SiteMinder r12.0 SP3, a warning message appears saying that the event handlers list should be set to XPSAudit.
Solution:
For SiteMinder r12.0 SP3, you can no longer add custom event handler libraries using the Policy Server Management Console. Use the XPSConfig command-line tool to add any custom event-handler libraries.
Symptom:
My Policy Server crashed while it was starting up. I want to know what SiteMinder startup events occurred before the Policy Server crashed.
Solution:
If the Policy Server crashes on startup, a log of the startup events is stored in the following file:
policy_server_home/audit/SmStartupEvents.audit
Copyright © 2012 CA.
All rights reserved.
|
|