Conflicting Token Certificate Status Information
133
The are two parts for enabling audit logging. The first is enabling the audit log itself, using the
Enable|
Disable
radio buttons. The second part is enabling
signed
audit logging. This signs the audit log after
every entry with a special signing certificate as a sign that the log has not been tampered with.
By default, the audit log is enabled, and audit log signing is disabled. After enabling logging, then
administrators can set what operations are recorded in the audit log. The loggable events are listed in
Table 9.2, “Events Recorded to the Audit Log”
, and logging for these events can be added or removed
from the audit log settings.
NOTE
Whenever the TPS audit logging configuration is changed, the TPS must be restarted for
the changes to go into effect.
Event
Description
AUDIT_LOG_STARTUP
The start of the subsystem, and thus the start of the audit function. This is always logged.
AUDIT_LOG_SHUTDOWN
The shutdown of the subsystem, and thus the shutdown of the audit function. This is always logged.
LOGGING_SIGNED_AUDIT_SIGNING
Shows changes in whether the audit log is signed. This is always logged.
AUTHZ_SUCCESS
Shows when a user is successfully processed by the authorization servlets.
AUTH_SUCCESS
Shows when a user successfully authenticates.
ENROLLMENT
Shows when a token is enrolled through the TPS.
UPGRADE
Shows when the applet on the token is upgraded.
AUTHZ_FAIL
Shows when a user is not successfully processed by the authorization servlets.
ROLE_ASSUME
A user assuming a role. A user assumes a role after passing through authentication and authorization systems. Only the default roles
of administrator, auditor, and agent are tracked. Custom roles are not tracked.
PIN_RESET
Shows when the password used to access the token is reset.
AUTH_FAIL
Shows when a user does not successfully authenticate.
CONFIG_SIGNED_AUDIT
Records when any change is made to the configuration settings for the signed audit log.
FORMAT
Records when a token is formatted.
Table 9.2. Events Recorded to the Audit Log
9.5. Conflicting Token Certificate Status Information
The TPS stores the complete history of certificates' status, so that all changes in status can be
reviewed. However, the status shown on the token is that last status of the certificate at the time the
token was formatted. The status of the certificates on the token may not immediately reflect the real
status of the certificates. It is possible to have multiple tokens with the same certificate information
on them; it then is possible for the certificate status on these tokens to become out of sync with the
status information in the CA database. When viewing these tokens in the TPS agents page, then, the
certificate information can be inconsistent.
For example, Token #1 has two certificates stored on it, an encryption certificate (Encrypt #1) and a
signing certificate (Signing #1). If Token #1 is lost, then both of its certificates are revoked, so both
Encrypt #1 and Signing #1 are marked as revoked. When the user is issued a new token, Token #2,
then Encrypt #1 is recovered, and a new signing certificate, Signing #2, is issued. The status for the
three certificates, then, is as follows:
