Skip links

Using SiteMinder Logs for Auditing

In this week’s article, we will examine the best logs for auditing user activity across your SiteMinder environment. Audit logs can provide a great amount of detail that can be used to analyze user behavior and application access patterns. As such, the logs discussed in this post are great targets for log aggregation. This data can also be fed into management and monitoring platforms to facilitate reporting and automated alerts. 

Policy Server – Audit Log

LogAudit Log
Default Namesmaccess.log
Location/{siteminder home}/log/
Enabled by DefaultNo

The policy server audit log is responsible for logging user activity related to protected resources. The log can be configured to capture the following events:

  • Authentication Events
  • Authorization Events
  • Affiliate (Federation) Events
  • Administrator Access Events

The contents of the log include the following:

  • Userids
  • Requested Resources
  • Web Agent Names
  • Requested Action
  • Session ID
  • Policy Server Names
  • Event Type
  • Date / Time
  • Partnership Name
  • Realm Timeout
  • Client IP Address
  • Events

This log is not enabled by default, but it can be configured using either smconsole or XPSConfig.  In order for the log to be populated, the audit event types desired need to be selected. The resulting audit data can be stored in a file, a database, or sent to a syslog server.   In our experience, sending the audit data to a database allows for easy, flexible reporting of user activity. Alternatively, the syslog functionality offers a great way to consolidate audit information, but the format of the data cannot be modified prior to transmission. To remedy that restriction, we recommend using a tool such as NXLog or Splunk to manipulate and aggregate the data. NXLog can also be used to send log contents to a database.

In terms of managing the policy server log files, the audit log facility can be configured to rotate the logs based on size or time and it can be configured to retain a certain number of logs.

Policy Server – Profiler Log

Default Namesmtracedefault.log
Location/{siteminder home}/log/
Enabled by DefaultNo

The policy server profiler log facility provides a robust logging mechanism that can be tailored to capture  user transactions and component debug information. The profiler can provide detailed information including, but not limited to, policy evaluation and response data associated with each resource request. The profiler is not enabled by default but can be enabled via smconsole or XPSConfig. 

The profiler relies on the smtracedefault.txt file (in the properties directory) to control the contents of the log. When modifying the configuration specified in the file, the SiteMinder administrator can do it directly or through the smconsole utility.    Use the profiler attribute and data selections in the smconsole to save the settings to smtracedeault.txt. After the attributes are saved, you can copy the file to a new name in the template directory for future use. The smconsole utility also provides a handful of templates to capture general information, with the templates being stored in the profiler_templates directory (in the config folder).

When it comes to the profiler log, log management is very important. That log file can grow rapidly and a very large profiler log can dramatically impact the performance of the policy server. Log rotation strategy for the profiler is configured in the smconsole file.

Unfortunately, SiteMinder does not provide a way to aggregate this profiler data; we recommend using a tool such as NXLog or Splunk to assemble the data for audit or analysis.

Web Agent / CA Access Gateway – Trace Log

LogTrace Log
Default NameNone
Enabled by DefaultNo

Available for web agents and the CA Access Gateway, the web agent trace log is not enabled by default. The following elements can be configured via the Agent Configuration Object (ACO):

  • TraceFilesToKeep
  • Traceformat
  • TraceDelimiter
  • TraceFile
  • TraceFileName
  • TraceFileSize
  • TraceAppend
  • TraceConfigFile
  • LogLocalTime

The ACO is also responsible for the log rotation and retention, while the WebAgentTrace.conf file is used to control the details captured in the trace log for web agents. The SecureProxyTrace.conf is used to control the details captured in the trace log for the CA Access Gateway.

There is no out-of-the-box mechanism to aggregate the trace log data. For many customers, we leverage tools such as NXLog to manipulate or aggregate the output. Using these tools allow you monitor the logs in real-time, thus enabling real-time metrics and alerting.  Once again, this aggregated data can be used to facilitate any required reporting.

Keep in mind that increased logging will impact the performance of the web agent and web server.  If you elect to enable tracing, make sure that you store the logs on a separate disk from the operating system and configure log rotation to avoid exceeding disk drive limitations.

Web Agent Option Pack – Federation Web Services

LogFederation Web Services
Default NameFWSTrace.log
Enabled by DefaultNo

Used to collect detailed SAML assertion information, the FWSTrace.log contains the encoded and decoded versions of the SAML assertions. If encryption is being used, the assertions will appear encrypted in the logs.

This log is not enabled by default and the file is used to configure the FWSTrace.log. Log rotation and retention is also configured in the same properties file. The contents of the file are controlled by the FWSTrace.conf file, which is configured a way that is similar to the WebAgentTrace.conf.  The web agent option pack provides four templates to facilitate configuration:

  • FWSTrace.conf
  • FWS_SSOTrace.conf
  • FWS_SLOTrace.conf
  • FWS_IDPTrace.conf

Unfortunately, there is no mechanism to aggregate the contents of this log file. Once again, we recommend using NXLog or Splunk to aggregate and correlate this information.

CA Access Gateway – HTTPD Client Log

LogHTTPD Client Log
Default NameHttpclient.log
Enabled by DefaultNo

The HTTPD Client Log records the requests between the CA Access Gateway server and backend servers. The log is not enabled by default; it can be enabled in the server.conf file. The logging level is controlled by the file on the CA Access Gateway. The contents include, but are not limited to, the following:

  • Action
  • Request Headers
  • User DN
  • JSON/XML Request
  • JSON/XML Response
  • HTTP Request / Response
  • Response Codes

The default configuration handles log rotation and retention, but it can be customized in the file. Using this log can greatly impact performance, so if you need to capture this information make sure that you have the proper I/O and disk space to accommodate the transaction volume.

There is no mechanism to aggregate this information; as mentioned previously, we recommend using NXLog or Splunk for that purpose.

As always, we hope that you have found this information useful. We will be dedicating a chapter in our upcoming SiteMinder 12.8 book to logging and the associated best practices, so keep an eye out for more information related to its release. If you need IAM assistance, reach out to SIS today and we would be happy to assist you. Finally, please subscribe to our newsletter to be notified about the posting of future articles and other SIS news.


If you want to know our recent offer please subscribe to our newsletter